cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathaniel Alfred" <Alfred.Nathan...@swx.com>
Subject RE: [RT] Micro kernel based Cocoon
Date Tue, 24 May 2005 14:54:51 GMT
> -----Original Message-----
> From: Daniel Fagerstrom [mailto:danielf@nada.kth.se]
> 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.

Mime
View raw message