2012/10/11 Francesco Chicchiriccò <ilgrosso@apache.org>
On 11/10/2012 00:38, Javier Puerto wrote:
> Hi all,
> I had working for an introduction talk about cocoon and I want lo
> leave the github link. The presentation is in Spanish because was for
> the http://barcampspain.com/ and
> http://www.congresohispanoluso.com/en/. Comes with examples made with
> cocoon 3.0 parsing a F1 sport webpage and serve the contents in
> different formats. If you are interested I can translate the
> presentation to English (examples and code are in English).
> Link: https://github.com/jpuerto/barcampes2012-cocoon
> Working on the presentation I did a proof of concept creating an
> Apache Tika generator. It's working but needs to enable caching and
> add the proper test cases and samples. If you are interested, I can
> finish it and commit changes.

It looks very cool :-)

Great, I will try to finish it soon.

> While I was working with cocoon at work time I started a
> OptimizerTransformer but I've found that IncludeTransformer is not
> cacheable so I worked first to get it cacheable (COCOON3-100)
> The transformer development is just at the beginning but before I
> continue to work with it I want your opinion. The idea is to use YUI
> compressor (BSD license) and define a custom language to define the
> static resources as CSS and JS. The transformer should review the
> resources, respect the order, compress the files and create optimized
> resources in a given path (to serve from Apache HTTPD with mod_cache
> and different domain). As this operation has a high cost, the
> transformer must control if the resource files changed. Finally, the
> transformer will place the proper tag with the URL for optimized
> static resources.
> WDYT? maybe there's better solutions (I know google HTTPD
> mod_pagespeed but it's always in beta state). The advantage is that
> you don't need to define everything at build time, with maven plugin
> for example so you can organize your static resources like you want
> (no one big file for all). On the other hand it has a high processor
> cost, but caching should minimize it.

This sounds very interesting as well: as you know, I've been working on
caching issues with XIncludeTransformer as well and I've ended up with a
temporary solution - mainly because I needed that for a customer of
mine. Actually, it is proving to be working quite well but your approach
seems to me largely better in the long term.  

> I didn't had time to work in Apache Cocoon 3.0 caching system since a
> couple of months ago. Recently, I had to switch the project and ATM
> I'm not working directly with cocoon. I want to take a closer look to
> the caching system when I can get some free time (COCOON3-30 and
> fragment caching), probably at December. Anyway, I will try to help in
> the mailing list and make some contributions like described above.

I was actually waiting for COCOON3-30 / COCOON3-100 to take breath for
cutting a M1 release (I know, we're talking of this since too much
time...); in C3 timing terms, December is like as tomorrow, hence I'd
like to support as soon as you'll be able to get back on this.

Maybe we can work on this in the hackaton at 5th November.

> I hope to see you soon in the ApacheCon,

Yep, me too: who's coming??? Chance to have a small Cocoon Get Together
(or just a beer) there?

Yeah!, we can continue discussion in the Thorsten thread.



Francesco Chicchiriccò

ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member