> -----Original Message----- > From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 24. Mai 2005 13:40 > To: dev@cocoon.apache.org > Subject: Re: [RT] Micro kernel based Cocoon > > > 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
I'm afraid history is repeating itself. In my perception the Cocoon core dependency on Avalon/Excalibur was a major PITA even before the community breakdown. A separate community (although large overlap with Cocoon), separate release cycles, separate repository, separate agenda, ... Everytime I wanted to debug something I hit a wall with no way to get at the source code. Always a datestamped JAR with some private fixes, completely unreproducable. With Eclipse, Knopplerfish, Spring or other it might be the same and even worse because of the missing insider links. Instead of a micro kernel which is going to have again a large footprint to do anything useful I'd rather prefer a small kernel to do just what Cocoon needs. After all Cocoon is just a super-servlet which needs a bit of container services for managing component reuse and state information. We should not make it again the playground for container academics. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
