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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org