cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: [cocoon-2.2] Deprecation
Date Mon, 05 Nov 2007 16:15:18 GMT
On Mon, 2007-11-05 at 12:49 +0100, Grzegorz Kossakowski wrote:
...
> > The second "big thing" for deprecation that we discussed in Rome was 
> > the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the
> > servlet:/ protocol doesn't provide all the "features" of the cocoon:/
> > protocol but that's mostly caused by getting rid of side-effects.
> 
> Yep. One of design goals of servlet: protocol was to share as less of environment as
possible while
> cocoon: protocol shares and mixes as much as possible. I firmly believe in first approach
that makes
> everything isolated thus simple and reliable.
> 
> We already have introduced quite advanced concepts like true OO in servlet service framework
so we
> should be very careful on not creating another "magic" box that nobody knows and everyone
is scared
> to fix or change.
> 
> There is a random thought: if we stick to the idea that environment is not shared between
caller and
> called service we get clustering for free. I think you could easily imagine several blocks
sharing
> services deployed to several separate machines. Then servlet services could be used remotely.
> Thanks to the fact that we use only standard HTTP you could even deploy one block to
several
> machines and use standard load balancer for balancing load of all machines serving some
servlet
> services...
> 
> WDYT?

Hmm, I must admit I am still catching up with the discussion around the
cocoon:// protocol, but must admit that it is quite essential in e.g.
forrest. 

We are making lots of use of pass-trough mounts and invocation of the
project specific sitemaps from the forrest core via cocoon:// calls. 

Now with the servlet: protocol (as I understand it) you need to know
before hand the name of the servlet you want to consult. This is not
practical in forrest where a project can be called as it want. Meaning
if cocoon:// is gone and no other protocol will offer the functionality
then forrest has a problem. 

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message