Vadim Gritsenko wrote:
Pier Fumagalli wrote:

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...

wait wait wait


I'm using Pier's terminology here: for 'content encoding' I'm thinking about 'gzip' stuff, not 'UTF-8'.

Currently pipeline does not alter content, does not affect content.

Right.


Addition of this attribute will bring content aspect to the pipeline concern... Do we really want it?

No, in fact, I think you got my terminology wrong.


I'm envisioning something like

 <map:pipeline encoding="gzip">
  ...
 </map:pipeline>

but I don't like "encoding", any idea for a better attribute?

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.

Right, we already have enough irons in the fire.


Stefano.



Reply via email to