[Thuban-list] term for extensions
jan at intevation.de
Tue Aug 19 22:57:00 CEST 2003
a decision on a branding term for the Thuban extensions is
apparently not yet to be done.
It is certainly a good idea to apply such a term for more formal
way to incorporate somthing into Thuban. Namely, this also means
that you could have independent install-packages.
Meanwhile Extension is still the most suitable name for what is done
e.g. via importing something through ~/.thuban/thubanstart.py.
We'll rename the directory extensions to libraries which is more
suiting anyway and create a new directory Extensions to place
any sort of extensions for the time being.
I've already written extensions to import GNS data and a rudimentary
import of ArcView APR files :-)
On Tue, Aug 12, 2003 at 01:17:36PM +0200, Bernhard Herzog wrote:
> Well, what do you mean precisely when you talk about a "Thuban
> Companion"? For instance, a Zope product is a very specific thing and
> there are ways to extend Zope without using products. So how does this
> compare to a "Thuban Companion"?
> I think that we have look at this from a few different angles:
> - What do you call an extension when you talk about the general concept
> of extending Thuban in a manual?
> - What do you call them in the user interface?
> - What do you call specific variants of extensions?
> Different kinds of extensions could be
> - New but perhaps simple commands in the menu
> - New interactive tools
> - Support for new file formats
> - Support for new database backends
> - What do you call the directory where you put those extensions that
> come with Thuban (the directory name was the main objection to using
> the term "extension")
> - What do we call an extension mechanism in the Thuban code?
> It seems to me that in the (introductory) documentation and user
> interface it's best to use terms that new users will understand more or
> less without further explanations. Most users have heard about
> extensions, plug-ins or add-ons, for instance.
> In the code it's a different matter. The developers of the "twisted"
> library for instance like to use unusual names (e.g. "jelly" for object
> serialization) not only because it adds some fun, but also because often
> the "normal" terms are already used for very similar but subtly
> different things by other projects.
> I'm not sure how well that argument would apply to Thuban, but at least
> terms like add-on or plug-in are quite heavily used for specific but
> always somewhat different ways to extend programs.
> I think "extension" is pretty generic for something that extends a
> program so I'd say we should use that as a collective noun for anything
> that extends Thuban. The only downside is that there's already a
> directory called "extension" in the Thuban sources which contains Python
> extension modules. On the plus-side that there's also a directory called
> simple_extensions in the Examples directory.
> "Companion" should then only be used for something more specific that is
> directly supported by some Thuban infrastructure. The modules in
> Examples/simple_extensions/ wouldn't qualify as Companions because they
> need some manual work by the user who has to modify his
> ~/.thuban/thubanstart.py module. To install a companion it should be
> enough to put it into a directory somewhere so that Thuban picks it up
> automatically on startup.
> Some other names some of which came up here in the office and some of
> which might be more appropriate as directory names or for the extension
> mechanism and not for the actual extensions:
> Corona (because Thuban is a star)
> Spice (because another star in the constellation Draco is Arrakis :) and
> because Spices let you adapt Thuban to your taste)
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
More information about the Thuban-list