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="foo.bar.GzippedReader"/>
</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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
