Stefano Mazzocchi wrote:
The problem with having an environment-dependent serializer is that the
cache needs access to it because it might change its behavior depending
on environment parameters.
IIRC, the reason why serializers are special WRT cache stuff is
exactly this (i.e. circular
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer. In fact, a chart
package image rendere *is* a serializer, since the output of a
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard to
write sophisticated Serializers.
We worked around this by using it in conjunction with a Transformer that
was given the environment and simply passed it
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to the
environment (Request / Response). This means that it is very hard to
write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
serializers)
We worked around this
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
Stefano Mazzocchi wrote, On 19/03/2003 14.41:
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer.
...
What's wrong with this?
I cannot
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support caching
since more
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer output
(as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough people believe this is a
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer
output (as binary) because their ergodicity can be different.
This is the only concern I'm having.
If
Nicola Ken Barozzi wrote:
Vadim Gritsenko wrote, On 18/03/2003 3.52:
Pier Fumagalli wrote:
...
That gets the value out of the serializer configuration itself... So,
per
se, we cannot have a per-pipeline text serializer with different
encodings
per different sitemaps...
That's why we have
Stefano Mazzocchi wrote, On 18/03/2003 10.37:
Nicola Ken Barozzi wrote:
...
Serializers, in the real world I mean, not in theoretical abstrations,
are efectively fisrt class components, not just adapters. IMO they
should be treated as such, because there is no real concrete reason
IMHO why this
Nicola Ken Barozzi wrote:
When my personal need comes, I surely will, although now I have other
things to do. If others want to write a more detailed proposal (Luca for
example) please do.
The *real* fact is that if I do:
xml data - chart transformer - batik - png
It's 10x SLOWER than
It gets quite complicated, because for the same URL the client might request
a Japanese, shift_jis, text/html view, while another might request a simple
image/jpeg...
It basically implies that the URL is a resource _for_real_ and that the
Resource - 'semantics' or 'the bit of info'.
Vary: *
which effectively disables any caching...
You bet :-) Though now one said that 'source IP' was a valid vary ;-)
Dw
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer. In fact, a chart
package image rendere *is* a serializer, since the output of a chart
transformer will not need
I am almost sure that it should be made all-the-way around: the client can
request a specific encoding to the server: See RFC 2616 section 14.2 page
102: the Accept-Charset header.
Or an _ordered_list_ of those as input. See also the Languages while you
are at it; and the Accept: type as
Pier Fumagalli wrote:
On 16/3/03 20:04, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, if you to put encoding into sitemap... You will have to disable
serializer configuration and request configuration and force sitemap
encoding onto request / response. Is this what you are proposing?
Pier Fumagalli wrote:
On 16/3/03 23:38, Vadim Gritsenko [EMAIL PROTECTED] wrote:
true. but you can't have chinese text in US-ASCII, right?
Even if you can not that anybody will be able to read it ;-)
So yes, right.
Unicode specifes (somewhere) that any character non representable by the
current
On 17/3/03 18:23, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote:
I am almost sure that it should be made all-the-way around: the client can
request a specific encoding to the server: See RFC 2616 section 14.2 page
102: the Accept-Charset header.
Or an _ordered_list_ of those as input. See
On 17/3/03 0:16, Vadim Gritsenko [EMAIL PROTECTED] wrote:
- String getCharsetEncoding() [or getCharacterEncoding]:
Returns the default character encoding configured for the specified
AbstractTextSerializer (or the default one for the sitemap if none
was specified).
This can
Pier Fumagalli wrote:
snip/
But there is a problem... Proxies and caches...
AFAIK (took a look at spec too ;):
If, for example, in my corporation there are two guys, one using Windows in
jp and one using Linux in en_US, if the first guy requests
http://www.vnunet.com/;, I'll deliver the page
Pier Fumagalli wrote:
On 17/3/03 0:16, Vadim Gritsenko [EMAIL PROTECTED] wrote:
snip/
It (?xml? instruction) done via
format.put(OutputKeys.ENCODING,encoding.getValue()) in abstract
serializer itself.
That gets the value out of the serializer configuration itself... So, per
se, we cannot
On Tuesday 18 March 2003 05:25, Pier Fumagalli wrote:
If, for example, in my corporation there are two guys, one using Windows in
jp and one using Linux in en_US, if the first guy requests
http://www.vnunet.com/;, I'll deliver the page the first time in jp,
encoded in shift_jis (let's not
Vadim Gritsenko wrote, On 18/03/2003 3.52:
Pier Fumagalli wrote:
...
That gets the value out of the serializer configuration itself... So, per
se, we cannot have a per-pipeline text serializer with different
encodings
per different sitemaps...
That's why we have to allow local serializer
Cocoon is heavily internationalized but we fail to do one thing: signal
the proper encoding to the user-agent thru HTTP headers, which is the
most reliable way of doing it.
the current *hack* is to use meta tags in the HTML stream, these are
interpreted by the HTTP server stack and transfered
Stefano Mazzocchi wrote:
Cocoon is heavily internationalized but we fail to do one thing:
signal the proper encoding to the user-agent thru HTTP headers, which
is the most reliable way of doing it.
the current *hack* is to use meta tags in the HTML stream,
Ew!
these are interpreted by the
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Cocoon is heavily internationalized but we fail to do one thing:
signal the proper encoding to the user-agent thru HTTP headers, which
is the most reliable way of doing it.
the current *hack* is to use meta tags in the HTML stream,
Ew!
I know.
Stefano Mazzocchi wrote:
snip/
I restate:
1) I want a way for serializers to indicate to the pipeline what is
the encoding they will be using, so that the pipeline can set the
right HTTP header for it.
2) also, i want a way to overwrite the sitemap-wide behavior of every
single serializers,
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip/
I restate:
1) I want a way for serializers to indicate to the pipeline what is
the encoding they will be using, so that the pipeline can set the
right HTTP header for it.
2) also, i want a way to overwrite the sitemap-wide behavior of
On 16/3/03 20:04, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, if you to put encoding into sitemap... You will have to disable
serializer configuration and request configuration and force sitemap
encoding onto request / response. Is this what you are proposing?
nonononononooo
please,
Stefano Mazzocchi wrote:
snip/
And, any of these are totally independent from the
internationalization. Internationalization affects language used to
produce output, but not how the text in this language is encoded
(UTF8, UTF16, ISO-1859-1, what-have-you).
true. but you can't have chinese
On 16/3/03 23:38, Vadim Gritsenko [EMAIL PROTECTED] wrote:
true. but you can't have chinese text in US-ASCII, right?
Even if you can not that anybody will be able to read it ;-)
So yes, right.
Unicode specifes (somewhere) that any character non representable by the
current charset-encoding
Pier Fumagalli wrote:
snip/
So, in my opinion, the best way to tackle the charset-encoding problem is
to have the org.apache.cocoon.serialization.AbstractTextSerializer to
receive an OutputStream from its implementation of the
SitemapOutputComponent interface, but to expose to its solid
37 matches
Mail list logo
