cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: A Gzipped XML Serializer component for Cocoon
Date Mon, 24 Mar 2003 13:51:57 GMT
There were some threads about on the developers list. IIRC they came to the 
conclusion to add such things to the pipeline. But after 2.1 release. One 
point in the discussion was, whether this is the task of Cocoon and not of 
Tomcat or Apache (mod_gzip).


Michael Riedel wrote:
> Hi Bruce!
>>I'm pretty sure this is something that eventually should be rolled into
>>Cocoon itself, but as I note in the page, my code is a hack on the
>>XMLSerializer, and shouldn't be ci'd as-is.
> Though I don't need it at this time, I agree, that gzip compression is a
> quite usefull. It should be included in the cocoon distribution.
> But I'm not sure, if compression should be handled by a serializer. What, if
> someone wants to compress something else than XML data. Then he'd have to
> rewrite another serializer to support gzip. (I have to admit, I don't have
> good application examples right now, since most of the other serializers
> produce some kind of compressed data anyway.) What I'm trying to say is,
> that compression is orthogonal to the actual data-format.
> Wouldn't it be more usefull, if compression was a seperate feature? I'd
> suggest a reader handling the gzip-compression.
> It could be used to compress any kind of data, both static and dynamic. To
> generate a compressed version of a dynamic resource, the reader could access
> the uncompressed version through the cocoon-protocol.
> (I have to admit, that I have never tried, if using the cocoon-protocol with
> a reader really works. But in my oppinion such an approach might be usefull,
> whenever non-xml data needs further processing.)
> Here is some sitemap fragment, to demonstrate my thoughts. It's only a
> scetch, so it might contain some bugs:
>   <map:readers default="resource">
>     ...
>     <map:reader name="gzip" src=""/>
>   </map:readers>
>   ...
>   <map:pipeline>
>     <map:match pattern="**.svg">
>       ...
>       <map:serialize type="svg2jpeg"/>
>     </map:match>
>     <map:match pattern="**.svgz">
>       <map:read type="gzip" src="cocoon:/{1}.svg"
> mime-type="image/svg+xml"/>
>     </map:match>
>   <map:pipeline>
> I'd like to hear other people's oppinion on this topic. If anyone is
> interested, I could try to refactor to gzipped-xml-serializer to a reader.
> I'd like to see if the above sitemap fragment really works.
> A possible problem, when seriallization and compression are seperated might
> be the caching-behavior. Can the output of a reader be cached at all? If
> yes, both an uncompressed and a compressed version would be cached. And
> then, does the cocoon-protocoll check if the requested resource has changed?
> If no, caching of the compressed resource would be useless.
> Greets, Michael Riedel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


System Development
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message