[Thuban-list] term for extensions

[Jan-Oliver Wagner]

Hi,

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:
> 
> Booster
> Amplifier
> 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)
> OortCloud
> GravityWell

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/

Intevation GmbH	              	     http://intevation.de/
FreeGIS	                               http://freegis.org/