cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: Preparing the new dojo-rsrc build
Date Thu, 11 Sep 2008 19:14:45 GMT
Hi Grzegorz

You are back early! Hope you had a good holiday. How was the sailing?

On 11 Sep 2008, at 13:57, Grzegorz Kossakowski wrote:

> Jeremy Quinn pisze:
>>> So i guess, there will be huge demand to keep all content locally.  
>>> Hence
>>> my favorite scenario would be szenario 3 plus a good documentation  
>>> of
>>> howto make different configurations.
> Agreed.
>> But as you mention below, in a production environment, no one in  
>> their right mind (whoops :) would serve static assets like Dojo  
>> from within a jar file, via Cocoon readers ..... much more sensible  
>> to serve it via Apache HTTPd.
> Jeremy, see Robin's suggestion about using Apache mod_proxy. Caching  
> files served by Cocoon makes much more sense to me than putting them  
> into some directory where httpd will serve them from.

I agree in principle, but do be careful with mod_cache, we found it to  
be very unreliable at high volume.

>> So IMHO, the primary use of the dojo-for-cocoon dist, is to be able  
>> to run the CForms Samples and do dev work.
>> So we either have the mega-build (full locale support etc.)  
>> currently weighing in at 6.5Meg, making it by far the biggest jar  
>> in Cocoon!
>> Or we go for my new nano-build (and a default to use Google CDN,  
>> which works extremely well BTW) weighing in at 12K !!!!!
> I don't know CDN service but for such a crucial component like Dojo  
> I wouldn't be happy that we rely on external, commercial entity that  
> probably gives no guarantees on how reliable its going to be.

Using CDNs is all the rage ..... when I first got CForms working with  
Google CDN, the first cocoon sample I tried, the page loaded almost  
instantly, some other site(s) I use must already have cached Dojo from  
CDN on my machine.

This is one of the real advantages of using a popular CDN.

>>> BTW: Isn't it an option to use maven2 capabilities ?
>> Please keep in mind that I am working on a solution which will be  
>> for both 2.1.x and 2.1.
>> If the maintainers of the maven dist so wish, they could distribute  
>> dojo-for-cocoon as either the build for using a CDN /and/ as a  
>> build to serve everything yourself.
>> But in the end, the only thing I think the mega-build is useful for  
>> is development offline. As making your own build is so easy (there  
>> will be an Ant build script in src/blocls/ajax/dojo) to me, it  
>> negates any need to add this extra 6.5Meg to Cocoon's distribution.
> It's good that you have mentioned working offline. I think it's  
> important as there are many developers willing to work offline. At  
> least for me it's crucial that Cocoon is fully functional without  
> fast or any internet connection.
>> Also keep in mind, that I hope it will become popular (and easy) to  
>> build a layer file specific to a single form or application  
>> (everything needed to support that form, packed into a single  
>> file). Again, this has the same production-deployment issues as  
>> serving Dojo itself.
> Different JS files for different Forms? Isn't it a bit of overkill?

Clearly it depends on the site and on usage patterns.
A single JS for a single form, or a group of forms, becomes cached,  
making re-access much faster.

> Also, keep in mind that in such case there is no chance for  
> efficient caching when you have many different forms.

You have to find the right balance between many hits to load separate  
small entities or fewer hits loading larger entities.

But in the end, what makes the most difference in forms people will re- 
use regularly, is a far-future expires header on JS, CSS etc..

> Just to sum up: For me relying on CDN should be optional way and not  
> primary one. The problem 6.5mb added to distribution exhibits only  
> weakness of 2.1 distribution system where you get "all-in-one"  
> package and you have no way to dynamically choose what you want to  
> download.
> As Hussayn already mentioned with Maven (and 2.2 obviously) this  
> will be different because you state your dependencies in pom.xml  
> file and its Maven that downloads dependencies on the demand so its  
> possible that we'll have two different "implementations" of Dojo  
> block.
> The use of CDN would be another solution but as I said I'm happy  
> with relying on external entity's services. At least not by default.

Well ATM unfortunately defaulting to use CDN is a mute point, as I  
mention in my last post, the Dojo on Google's CND is not high enough  
quality build for our needs.

Hopefully that will change.

regards Jeremy

View raw message