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
- Re: [RT] Micro kernel based Cocoon Daniel Fagerstrom
-
