[texworks] SCRIPTING: Web page Linking back into Issue 261 Scripts

Charlie Sharpsteen chuck at sharpsteen.net
Mon Jul 25 19:49:12 CEST 2011

On Fri, Jul 22, 2011 at 11:59 PM, Stefan Löffler <st.loeffler at gmail.com>wrote:

> **
> On 2011-07-21 20:41, Charlie Sharpsteen wrote:
> An interesting idea for the future would be to develop a central script
> repository and a "plugin manager" inside TeXworks that makes it easy for
> users to find, download and install plugins.
> In principle, this is a great idea. However, there are a few problems with
> this (or else we'd probably have it by now ;)).
> First is quality management. With a central repository, it could be easy
> for people to get the impression that all those scripts are part of/endorsed
> by Tw (especially when such a repository is hosted on some official server).
> I know, things like this work for other programs (including, e.g., Mozilla
> Firefox), but Tw scripting is intended for everybody, not just hard-core
> coders, so if this picks up as intended, I guess there will always be
> scripts than have the one or other bug, don't work on some platform or
> other, etc.
> And in any case, someone would have to maintain such a platform (evaluate
> scripts, remove problematic ones, etc.)
> On a more technical side, this would probably be a fairly major web program
> (with upload functionality, database backend, etc.). We certainly can't host
> that on tug.org, as they don't have PHP or similar enabled AFAIK (at least
> not globally). And unless there are such websites ready-made (like for blogs
> or CMS), this would be a major undertaking.

Well, one way to approach this would be to set up
the repository machinery so that any enterprising power user, such as Paul,
could easily set up their own repository. Then other power users could enter
the repository's URL into the plugin manager to get easy access to the
contents. This would hopefully dispel any impressions that the scripts were
officially endorsed or supported by TeXworks.

As for hosting, it doesn't need to be that complicated---there is no need
for a server application if the repository system is set up to operate using
static files listed in some sort of central manifest. QGIS uses an XML
manifest and the R programming language uses a simple text based manifest
for CRAN packages. I once set up a CRAN server that operated out of a SVN
repository.  If static files are used then there are a lot of
options---Dropbox, SourceForge, GitHub Pages, Google Files, etc.

If a server is needed to dynamically create and update content, then we are
blessed in that the scripts and associated metadata are only a handful of
megabytes. A simple 100 line Sinatra <http://www.sinatrarb.com/> server
running on a free Heroku <http://www.heroku.com> account could probably
handle the task just fine.

A plugin repository system would take some time to set up, but the result
would probably be more visibile, accessible and maintainable that just
listing scripts in a Google Code issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110725/647e4a90/attachment-0001.html>

More information about the texworks mailing list