RFC: centralise registries

[Brian de Alwis]

On 14-Apr-2009, at 3:30 AM, Robert Collins wrote:
> I think actually the root of the issue is that there is no way for a
> plugin to say 'I would register with some X but I don't want to  
> trigger
> that X'. twisted achieves this by plugin metadata - plugins are a Y,  
> and
> this is memoised and then the plugin is called into for Y  
> operations. I
> think this is overly constraining.


FWIW: Eclipse uses XML to represent plugin extension metadata to defer  
the overhead from loading jars until absolutely necessary.  It's a  
powerful model and seems to correspond very well to the existing  
bzrlib registries.  So switching to an XML description wouldn't  
require too much work, once the actual XML metadata parsing has been  
written.

Each plugin provides an XML descriptor, found in the root of each  
plugin and called plugin.xml.  These plugin.xml are read in at first- 
load.  The plugin.xml defines: extension points, which are essentially  
well-defined names, and extensions, which provide extensions to those  
extension points.

An extension point is defined as follows:

	<extension-point id="sample" schema="relative/path/sample.exsd" />

The id is catenated to the plugin identifier (defined in the plugin's  
META-INF/MANIFEST.MF file) to form a unique extension point name.   
Extension points carry an optional schema to describe what extensions  
should provide in their XML fragment.

Extensions specify a unique extension point name and provide some XML  
stanzas that fit the schema.  For example, this is what I use in one  
of my tools to define a view within Eclipse.

    <extension point="org.eclipse.ui.views">
       <category
             id="ca.ubc.cs.ferret.views.categories"
             name="Ferret">
       </category>
       <view
             id="ca.ubc.cs.ferret.views.QueriesDossier"
             name="Ferret"
             icon="icons/ferret-1.gif"
             category="ca.ubc.cs.ferret.views.categories"
             class="ca.ubc.cs.ferret.views.QueriesDossierView">
       </view>
    </extension>

The schema is optional -- it exists to provide tooling support for  
developers when creating an extension.  It can specify orderings and  
cardinalities of stanzas, as well as specify that certain attributes  
must correspond to a particular Java type.

Brian.

-- 
"Amusement to an observing mind is study." - Benjamin Disraeli