cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] what about cocoon on a diet?
Date Sat, 16 Apr 2005 15:45:00 GMT
Stefano Mazzocchi wrote:

> I just hit a limitation of cocoon that I never thought I would 
> encounter on a server framework: it's too big!
> We (at MIT) are implementing a pretty complex web application for RDF 
> search and browse interface (Longwell) and I'm about to start the work 
> to support our work done on RDF presentation ontologies (Fresnel).
> Currently, the 'framework' driving Longwell-2 is an in-house little 
> thing called "Flair". Previously, in Longwell-1 it was some simple 
> servlet.
> We don't use pipelines (not yet at least), we don't keep state [it's 
> fully REST-ful, but not sure how long we can keep that], we don't use 
> forms (yet, but the need is approaching fast), we don't have a big 
> group of people working on it (so SoC is not a big deal), I'm the only 
> one that knows cocoon (even if this is not hard to change given that 
> my colleagues are all twice as smart as I am) and we work with MIT 
> grad students, who are notorious for having a problem dealing with 
> anything that was not invented there.
> These are all things that kept me away from moving longwell over to 
> cocoon, but when the need for web-based RDF editing came along, I 
> thought there was no way I would have allowed to reinvent flowscript 
> and cforms, so I was about to start moving it when something else hit 
> me over the head.
> One day, out of the blue, one of our graduate students takes longwell, 
> writes an XPCOM component around it and ships it with his RDF-enabling 
> Firefox plugin.
> I hit the breaks with both feet.
> His work was so cool and groundbreaking (AFAIK, he built the first 
> java-based firefox extension ever) that radically changed the way we 
> thought about our own tools and how they could be used: having the 
> ability to do a one-click installation of our java-based webapps 
> *inside* your browser simply blew me away.
> Problem: the first version of our XPI was 11Mb. Firefox is 5Mb on 
> windows, 8Mb on a mac. It doesn't feel right.
> Size is preventing me from porting Longwell over to cocoon and finally 
> attempt to start building that bridge between cocoon and RDF.
> I spoke with Sylvain about this as his company has some 4Mb version of 
> cocoon for embedding. He told me to use ProGuard.
> I did.
> Piggy-bank 1.0 was 11Mb. Piggy-bank 2.0 is now approaching 1.2Mb, 
> after rearchitecture, change of RDF triple/store and proguard 
> shrinking (this included everything, including jetty!).
> Now it's reasonable: 1.2 xpi extension and 5Mb browser. sounds about 
> right. and hides very well the fact that this 1.2Mb contains:
>  - a web server (jetty)
>  - a servlet engine (jetty)
>  - a full text indexer (lucene)
>  - a template system (velocity)
>  - a log system (log4j)
>  - an RDF database (sesame)
>  - a publishing framework (flair)
>  - a facetted-browsing RDF engine (longwell)
>  - a liveconnect-capable classloader
>  - the XPCOM layers
>  - the XUL/CSS/javascript files
>  - the icons and images
>  - the XHTML templates
> Pretty impressive.
> But Flair is 30Kb and Cocoon is 15Mb. Even shrunk, 4Mb is still too much.
> So, my question for the group is: how can we make the cocoon core even 
> smaller?
> It would suck pretty bad if our group had to rewrite parts of cocoon 
> just because of the many dependencies and size :-(

Run ProGuard on a Cocoon application and have a look at what's still 
there: that will help us to know where the shrinking effort should go or 
what components need to have a smaller (possibly less featured) new 

We're able to have a Cocoon application and our own servlet engine (70kb 
before shrinking) in less than 1Mb. But this is using the compiled 
sitemap engine and precompiled translets with xsltc. IIRC the 
TreeProcessor eats about 200kb, but we may use the Mozilla XSLT 
processor to avoid embedding Xalan or Saxon.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message