cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Preparing the new dojo-rsrc build
Date Thu, 11 Sep 2008 12:57:49 GMT
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.


> 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
much more sense to me than putting them into some directory where httpd will serve them from.

> 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.

>> 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?

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

Just to sum up: For me relying on CDN should be optional way and not primary one. The problem
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
services. At least not by default.

Grzegorz Kossakowski

View raw message