On 17/3/03 20:15, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:<snip/>
What about adding a 'content encoding' attribute to the 'pipeline' instead?
'transfer encoding' attribute would make sense, but content encoding... Currently pipeline does not alter content, does not affect content. Addition of this attribute will bring content aspect to the pipeline concern... Do we really want it?
Right now, to make things work in 99.9% of the cases, I'd say that we add this to the pipeline, and right now, we enforce this onto the client. So, no matter what he asked in the different "Accept*" headers, we deliver them what _we_ want...
Same could be done now with serializer configuration, right?
As negotiating the encoding/type/language is something that will also affect
widely our cache, I propose to defer this to Cocoon 2.2 (or later) when the
problem can be analyzed thoroughly in more details...
+1
Now, does anyone have suggestions on how to retrieve the "charset" value out
of <map:pipeline> ??? Where would be a nice place in our API?
PipelineNodeBuilder. But I would postpone such a thing to Cocoon 2.2 too.
Vadim
On a side not, currently, "AbstractTextSerializer" relies on Xalan as its way to generate content, but, IMO, there could be other text serializers not needing it (ok, it's JAXP! :-)
Pier
