Sylvain Wallez wrote:

Daniel Fagerstrom wrote:

Sylvain Wallez wrote:

<snip/>

We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support.

I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details?

The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a "source-factory" extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system.

For this specific usecase, the URL service of OSGi could also be of interest. But in general extension points could be useful.

AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also.

Ok. One one hand it is good to leverage on whats in Eclipse. OTH it seem to introduce quite a lot of bulk, even the platform download from Eclipse is some tens of MBs. Maybe one can use a much smaller part of Eclipse. To me it seem atractive to being able to chose between several implementations of OSGi and that e.g. the framework implementation from Knopplerfish starts at 200KB.

/Daniel

Reply via email to