cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [GSoC_2008] Project ideas
Date Sat, 29 Mar 2008 14:34:27 GMT
Grzegorz Kossakowski pisze:
> 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.
>                                               --- 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.

Argh, I forgot about very important issue:
Who is going to be my mentor? Any volunteers on board? :-)

Grzegorz Kossakowski

View raw message