cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] what about cocoon on a diet?
Date Sat, 16 Apr 2005 15:06:52 GMT
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 

It would suck pretty bad if our group had to rewrite parts of cocoon 
just because of the many dependencies and size :-(


View raw message