On Dom, 1 de Mayo de 2005, 15:27, Sylvain Wallez dijo: > Daniel Fagerstrom wrote: > >> Sylvain Wallez wrote: > > > <snip/> > >>> By using the Eclipse kernel, Cocoon could be the first RSP, "Rich >>> Server Platform". >>> >>> WDYT? >>> >>> Sylvain >>> >>> [1] http://www.eclipsefaq.org/chris/faq/faq-list.html >> >> >> Cool! But not that you took my forthcomming RT ;)
:-) Seems like we finally found the answer to: <quote href="http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110915670913345&w=2> ...Because having it as a block makes it really hard to answer the question: what is cocoon and what does it provide me.... </quote> I am happy to see that you found a good answer to the question! ... sound like Cocoon becomes to be more interesting like ever .... going to a new level. This is super-great! :-) Best Regards, Antonio Gallardo. > > > Ooops, sorry :-) > >> I have also been thinking in this direction the last few days. >> Reinhard reminded me about that you had proposed OSGi >> http://www.osgi.org/osgi_technology/index.asp?section=2 as a possible >> kernel. So I have taken a look at that and a little bit on Equinox, >> the new Eclipse kernel that is based on OSGi. Other possible kernels >> are Pier's, the Geronimo kernel and Metro. Of these I find >> Eclipse/OSGi the far most promissing. > > > Actually, the idea of OSGi has been running in my head for a long time. > I discovered OSGi when working on the embedded Cocoon, as we had to make > an OSGi bundle with it so that it can be added to an OSGi-powered system > in a car. OSGi is widely used in embedded systems, especially automotive > and intelligent gateways. > > Then came the interesting convergence between embedded system and > "normal" systems when the Eclipse folks decided to trash their > proprietary kernel in 3.0 in favor of OSGi. The resulting kernel has two > layers: OSGi takes care of all classloading stuff whereas the Eclipse > plugin system takes manages extension points and the associated plumbing. > > When learning to write Eclipse plugins a while ago, I found some > interesting similarities between what Eclipse provides and the Avalon > semantics we're used to. Writing plugins is amazingly easy. Firstly > because Eclipse provides an incredible PDE (plugin development > environment) that guides you through the various tasks needed to write a > plugin. And secondly because each plugin being isolated in its own > classloader, there are a lot of issues that go away. For example, using > static attributes is no more a problem! > >> I agree completely with that a micro kernel Cocoon is the way to go. >> It would as you say give most of what we want for blocks and also >> numerous other possiblities in building Cocoon based apps. It would >> also help us in getting Cocoon far more managable if we package it as >> a bunch of bundles. > > > Yup. > >> I'm making good progess with the pipeline service aspect of blocks and >> will hopefully be able to check in some code for it soon. When we have >> a working prototype of that part, I'm interested in diving into the >> Eclipse stuff. > > > Great! > >> Have you thought about how to make OSGi work together with ECM++, or >> can they just be considered as different layers? > > > OSGi could be the top-level container, allowing each plugin/block/bundle > to use ECM++ if it wants to. But my feeling is that most blocks won't > need to have their own container. > >> Anyway, cool stuff :) > > > Definitely ! > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://apache.org/~sylvain http://anyware-tech.com > Apache Software Foundation Member Research & Technology Director >
