[udig-devel] Extention point processing

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Hi guys I found some problems w/ a recent review of 
ExtentionPointUtil.process( ExtentionPointProcessor ).

And for once these are real problems so I will bring them to everyones 
attention. But first the code ...

> public static void process(String xpid, ExtensionPointProcessor 
> processor) {
> IExtensionRegistry registry = Platform.getExtensionRegistry();
> IExtensionPoint extensionPoint = registry.getExtensionPoint(xpid);
> if( extensionPoint==null ) return;
> IExtension[] extensions = extensionPoint.getExtensions();
>
> // For each extension ...
> for (int i = 0; i < extensions.length; i++) {
> IExtension extension = extensions[i];
> IConfigurationElement[] elements = extension.getConfigurationElements();
> // For each member of the extension ...
> for (int j = 0; j < elements.length; j++) {
> IConfigurationElement element = elements[j];
> if( !processor.process(extension, element) ) // EEK 1
> break; // EEK 2
> }
> }
> }

The problems are this:
EEK1: This, by definition, passes control off to an external plugin, and 
does not catch exceptions. One bad plugin could break everything ..
EEK2: Allowing an extention to skip extention point processing forces 
contributors to interact. One plugin can mask out others, the order of 
extention points is not fixed, so we esentially have random behavior.

Here are the Extender Rules:

> Invitation: Whenever possible, let others contribute to your contributions
> Lazy Loading: Contributions are only loaded when they are needed
> Safe Platform: As the provider of an extension point, you must protect 
> yourself against
> misbehavior on the part of extenders
> Fair Play: All clients play by the same rules, even me
> Explicit Extension: Declare explicitly where a platform can be extended
> Diversity Rule: Extension points accept multiple extensions
> Good Fences: When passing control outside your code, protect yourself
> User Arbitration: When there are multiple applicable contributions, 
> let the user decide
> which one to use
> Explicit API: separate the API from internals
> Stability: Once you invite someone to contribute, don’t change the rules
> Defensive API: Reveal only the API in which you are confident, but be 
> prepared to reveal
> more API as clients ask for it