cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [GSoC_2008] Project ideas
Date Sun, 30 Mar 2008 12:19:23 GMT
Grzegorz Kossakowski wrote:
> Vadim Gritsenko pisze:
>> On Mar 17, 2008, at 11:30 AM, Grzegorz Kossakowski wrote:
>>> Reinhard Poetz pisze:
>>>> My statement was meant to be more general (SSF + Spring migration + 
>>>> Schema support).
>>>> For an SSF project only, I don't see enough work (I only know about 
>>>> SAX buffering and support for redirects as missing features) ... but 
>>>> maybe I'm wrong here.
>>> There is not that much work left in "pure" SSF 
>>> (cocoon-servlet-service-impl module) but there is still a room for 
>>> improvement in module containing components integrating SSF and 
>>> Cocoon (cocoon-servlet-service-components). Mentioned SAX buffer 
>>> support involves modifications in impl and components modules.
>>> I would add to the list of nice-to-have-in-SSF servlet discovery 
>>> feature based on some conditions (e.g. returning 200 status code as 
>>> response to certain request path). This way one could discover blocks 
>>> providing certain services (e.g. skinning).
>>> Nothing more comes to my mind right now.
>>   $ find 
>> cocoon/core/cocoon-servlet-service/cocoon-servlet-service-impl -name 
>> "*.java" | xargs grep TODO | wc -l
>>   18
>> I'm not so sure that this is "not much" :)
> Vadim, you forgot about FIXME marks ;)
> find core/cocoon-servlet-service/cocoon-servlet-service-impl -name 
> "*.java" | xargs grep -E "TODO|FIXME" | wc -l
> 27
> I've been considering participation in GSoC for some time due to my 
> tottering planes for summer.
> Now I'm pretty sure I'll be able to do some Cocoon-related work again 
> this year. I would like to focus on fixing bugs, implementing lacking 
> features and general polishing SSF.
> My goals would be:
>   * get rid of most FIXME/TODO marks in SSF code
>   * implement SAX buffering for service calls
>   * fix COCOON-1964:  Redirects inside a block called via the servlet 
> protocol fail
>   * fix COCOON-2096:  Servlet source's exists() method always returns true
>   * provide samples of SSF usage for both situations:
>     - servlets managed by SSF are pure servlets that have nothing to do 
> with Cocoon itself
>     - servlets are both pure servlets or SitemapServlets
> For samples I would like to prepare examples how to connect, call 
> servlets. How to make service calls, make use of polymorphism, etc.

I'm not sure, but isn't there some open issue with multi-part mimes handling? 
Apart from this, the list seems to be complete.

>                                               --- o0o ---
> Apart from that I have an idea of making Cocoon blocks/servlets 
> distributed and enabling SSF to transparently handle such set up. I 
> think it would be very interesting to have a possibility to deploy 
> different servlets to different physical machines and let them talk to 
> eacher other using HTTP.
> Actually, current implementation of servlet-to-servlet connections 
> exploits only standard HTTP API so this should be quite easy to 
> implement. That would enable completely new-brand SSF usage patterns like:
>   * setting up load balancer between blocks (servlets) provided there 
> are few machines with the same block deployed
>   * setting up fail-over handling (if one of machines goes down, rest 
> takes the processing)
>   * exceptional scalability: if one of blocks is being used extensively, 
> you can add another machine with this block deployed and make load 
> balancer aware of it
>   * even block (servlets) calls through the Internet! :-)
> This should be considered as an optional deliverable for my GSoC 
> activity as it would demand lots of discussing, researching and 
> implementing in the end. Nevertheless, if time permits I would like to 
> start experiment with this idea during the summer.

Definitly and interesting topic and making it an optional deliveralbe is a good 

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message