Extension Architecture

[Jonathan Coles]

concerning the extension architecture that we've been discussing:

i believe the ExtensionRegistry is the right way to go. i was about to
write one myself when i noticed that there is already one in UI/.
however, this class should not be in UI but in Model because extensions
are a concept which is not specific to the UI but a generic feature of
thuban. All extensions should be required to register before they can be
used and the add() method should also take an Extension instance. 

to add hooks that extensions can use there should be a generic class
perhaps called ExtensionHook that is extended by parts of thuban that
wish to provide a clean interface to extensions. this class would have
one or more "add" methods which take as arguments the Extension instance
created by the extension and whatever other arguments are appropriate
for the hook (e.g. one or more callback functions). these add functions
would first check that the extension has been registered by calling a
function in the parent ExtensionHook class. they might even allow an
extension to register multiple times (?).

if we provide a nice ExtensionHook class we provide a consistant
interface for adding extensions rather than what we have now with the
renderer and layer properties, which is somewhat inconsistant.

i prefer this method of allowing each part of thuban to control its own
extension handling for two reasons: 

1) the alternative may to be create one large class that has methods for
   all the different hooks available. the biggest drawback i can see is
   that this would mean including UI hooks in the same class as Model
   hooks. to avoid this, one could create two hook classes, one for UI
   and one for Model, but this is not really any better than having
   each part create its own hook mechanism, and could make it harder to
   add other hook classes in the future.

2) more importantly than reason (1) is that extensions could themselves
   provide extension points. yes, this could cause extension dependency
   issues, but could also make thuban much more flexible and powerful.
   since all extensions are registered before they are initialized, it 
   should be possible for extensions to determine whether all the
   necessary dependancies are present.

the ExtensionRegistry should be made smarter. perhaps the extensions
should be allowed some freedom in determining whether multiple versions
are allowed. for instance, what if the init_callback function took a
list of other extensions that have been registered with the same name?
if the list is non-empty then init_callback could determine if is should
unregister itself if it has a lower version than what is provided.

allowing multiple versions is a good idea if different versions handle
input files differently. rather than worrying about backward
compatibility an extension could allow different versions to co-exist
within thuban.

a true conflict can be signalled by the return value from init_callback.
in such cases the user can be shown a list of problem extensions and
decide whether or not to proceed.

that's all for now. :)

thoughts?

--jonathan

-- 
=====================================================================
 Jonathan Coles                               http://www.jpcoles.com
 jonathan at jpcoles.com                    GnuPG Key: /gpg_pub_key.asc
=====================================================================