cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Mon, 05 Nov 2007 13:37:40 GMT
Grzegorz Kossakowski schrieb:
> Reinhard Poetz pisze:
>> I think that you refer to the idea of deprecating sub-sitemaps which
>> isn't an as good idea as it seemed from a quick glance because there is
>> no equivalent to get the same functionality if you have to replace it
>> with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps
>> for deprecation.
> 
> Solution does not exists *yet* but I guess we could find some replacement as soon as
we know what
> functionality is lacking. AFAIR, Vadim mentioned following construct:
> 
> <map:match pattern="...">
>   <map:act type="prepareSomething"/>
>   <map:mount .../>
>   <map:act type="finilazeSomething"/>
> </map:match>
> 
> that cannot be replaced by use of Servlet Service Framework, right? If it's the only
use-case (mount
>  surrounded by some initialization code) I guess we could easily find something equivalent.
> 
> Are there any other examples?
> 
>> IIRC it wasn't the functionality of <map:mount> that made some people
>> think that we should deprecate sub sitemaps but the <map:components>
>> part of sitemaps which causes a lot of complicated code that we have to
>> maintain. However, deprecating <map:components> shouldn't be a problem
>> because there already exists a migration path of putting your component
>> definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon.
> 
> Not only <map:components/>. Mounting + cocoon protocol makes whole core unnecessary
complicated and
> lacking of separation. Mounting involves creation of new context, cocoon calls affect
code of
> sitemap and pipeline handling very deeply which is a bad sign IMO.
> 
>> 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?
> 
>> Can somebody who knows the code and the functionality of
>> <map:components> and cocoon:/ in more detail than me comment on this?
> 
> I know cocoon:/ protocol quite well and I can assure that with conjuration of map:mount
it's very,
> very problematic part of Cocoon.
> 
> It's also not a good idea that we are going to have two competing solution for achieving
the same,
> yet core functionality of Cocoon.
> 
>> I think we should discuss these two big topics first and then we can
>> continue with smaller things like the SimpleFormsTransformer, obsolete
>> input modules, etc. I hope that I find some time soon to write a summary
>> that contains a list with all those components.
> 
> Yep.
> 
> Thanks Reinhard for bugging us on this topic and sorry for delays. I have finally some
free time
> that I can devote to Cocoon now.
> 
Rethinking the whole topic, I guess it boils down to the question of
what the best approach is (that's obvious of course). So I think we
should first think about how we envision applications are built with
Cocoon considering all known use cases. This includes questions like "do
we think sub sitemaps are a good idea?" etc. Once we have agreed on this
we can think about how this maps to the way people are building their
applications with Cocoon today (with 2.1.x) and then think about
deprecating stuff, changing stuff or leaving it as it is.

And I'm coming back to a point I mentioned at the GT which everyone
ignored :(, I still think that one possible solution of a migration plan
is to run a Cocoon 2.1.x installation inside 2.2.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message