[Thuban-list] term for extensions

[Bernhard Herzog]

Jan-Oliver Wagner <jan at intevation.de> writes:

> On Fri, Aug 08, 2003 at 12:31:11PM +0200, Jan-Oliver Wagner wrote:
>> A new proposal was "Companion" in order to have some sort
>> of special branding. Like "Product" for Zope.
>> So, we might want to use  the term "a Thuban Companion" analog
>> to "Zope Product" ?
>> Further thoughts?
>
> no further thought came in.
> 'Companion' had the most pro's so far (though in total not many
> comments arrived).
>
> So, if noone objects soon (perhaps with a better alternative :-)
> the Thuban extensions will be called Thuban companions.

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

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/