Hi Javier,

ok, that makes sense now. In what seem like the distant past we talked about a bunch of things that could be done to the C2 caching systems. I haven't ever dug into what has been done with C3 so I can't really guess at how any of that would apply, but if I was starting from scratch I'd be giving some consideration to event driven cache invalidation and maybe even using memcached.

Peter Hunsberger


On Fri, Oct 12, 2012 at 6:58 AM, Javier Puerto <jpuerto@gmail.com> wrote:
Hi Peter,

I've open a new thread as Thorsten did because I opened too many things in a single mail. :)

2012/10/11 Peter Hunsberger <peter.hunsberger@gmail.com>
Hi Javier,

not quite sure what you are asking about?  I know you're asking about caching implementations, but it's not clear what the problem is in general that you are addressing, or is this just a solution for a very specific problem?  Is this caching Cocoon resources, HTTP level caching or maybe even something in between?

There's no problems in Apache Cocoon 3.0 caching system. It's working OK but I think that it could be better. With old cocoon releases, the caching system relies on the now discontinued framework Apache Excalibur [1].

Cocoon 3.0 was rewritten to remove dependencies for these frameworks. Now, it has something similar now but it's lacks support for fragment caching [2] [3]. If a pipeline has a component that is not cacheable, the whole pipeline will be processed. With fragment caching all the components results are cached so the pipeline will start the execution with the first non-cacheable component. This can be minimized splitting big pipelines into smaller ones but sometimes is not desirable.

When Francesco and I worked making the XIncludeTransformer and IncludeTransformer cacheable respectively, we found that we had to create something similar to old caching style. So I wonder if we can put some effort to migrate the old caching system, see discussion in [4].

At end we need to add Javadoc to the current caching interfaces [5].

Salu2

[1] http://excalibur.apache.org/
[2] http://cocoon.apache.org/2.2/core-modules/core/2.2/675_1_1.html
[3] http://cocoon.apache.org/2.2/core-modules/core/2.2/690_1_1.html
[4] https://issues.apache.org/jira/browse/COCOON3-102
[5] https://issues.apache.org/jira/browse/COCOON3-92

 

Peter Hunsberger



On Wed, Oct 10, 2012 at 5:38 PM, Javier Puerto <javier@apache.org> 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.

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.

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 hope to see you soon in the ApacheCon,
Salu2.