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 <jpue...@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.hunsber...@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 <jav...@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. >>> >> >> >
