Re: A Gzipped XML Serializer component for Cocoon
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).
Joerg
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=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]
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Gzipped XML Serializer component for Cocoon
Quoting Joerg Heinicke [EMAIL PROTECTED]: 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). Joerg 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... Michael, Joerg: On the issue of if this being handled by mod_gzip or mod_deflate, Apache's own Batik Squiggle does not, in my experience, receive compressed SVG if compression is handled this way. Nor do I see why it should send a Accept-Encoding: gzip header to get *.svgz, since they are not a compressed form of the original (like html that has been gzipped by the above), but rather a proper manifestation of the document, like jpg compression. Secondly, there is the issue of sparing your cache. See the introduction to my http://wiki.cocoondev.org/Wiki.jsp?page=Gzip_XML_Serializer (I would post this to the dev group, but I never seem to be able to get subscribed to that.) I can see Michael's argument for a reader-based implementation, but efficient caching is a sine qua non for me. Could something be done with a view? I'm glad to hear this is on the radar of the developers', for whose hard work I am most grateful. Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Gzipped XML Serializer component for Cocoon
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]
A Gzipped XML Serializer component for Cocoon
I have posted a Wiki page describing a serializer component I'm using which produces gzipped XML output. This is especially useful for those serving complex SVG and would rather send it off as a svgz file. 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. Details at: http://wiki.cocoondev.org/Wiki.jsp?page=Gzip_XML_Serializer Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Gzipped XML Serializer component for Cocoon
Hi Bruce, nice work! I have not tried it out yet, but it looks promising! Do you work for that projekt http://heml.mta.ca/heml-cocoon/ ? I find it a very nice example using cocoon and SVG! King regards Thorsten Scherler Bruce Robertson wrote: I have posted a Wiki page describing a serializer component I'm using which produces gzipped XML output. This is especially useful for those serving complex SVG and would rather send it off as a svgz file. 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. Details at: http://wiki.cocoondev.org/Wiki.jsp?page=Gzip_XML_Serializer Yrs, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
