Torsten Curdt wrote: >>Having in front of this setup a reverse proxy would massively help in >>building scalable sites, since many resources would be served by Cocoon >>only once in a while, with the proxy doing most of the job. My first >>tests are astonishing: with this setup scalability in most cases won't >>be an issue anymore. Not to mention usability in developing webapps: >>there would be no need anymore to mix and match static resources served >>by Apache for speed and scalability sake and synamic stuff served by >>your favourite app server: anything can be safely enclosed inside a >>webapp. Last but not least, this can be an enourmous bandwith saver. > > > I always thought this would be a good thing. Have you implemented it for the > compiled sitemap, for the treeprocessor or for both?
Alas, I was too short on time to catch up both with TreeProcessor anc compiled sitemap, so as of now this is available only on TreeProcessor. I might do my best to reconcile this change and port it to the compiled sitemap too, but I don't expect this to be an easy task. Besides, I think this is about time to discuss about this issue and put some rules. I see these possible choices: 1. choose one implementation (be it treeprocessor or compiled) and stick to it; 2. keep both, and let developers work with the one they prefer (with possible out of synch changes); 3. keep both, but refuse to release components that work only with one sitemap engine. Personally I'd go for 1 and choose treeprocessor, unless there are benchmarks stating that a compiled sitemap is definitely faster. 3 is good to, but I'd avoid 2 as hell. Are there any incompatibilities as of now? Ovidiu: did you implement Schecoon even for the compiled sitemap? Ciao, -- Gianugo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
