cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: When to set mime-type
Date Wed, 27 Oct 2004 14:41:58 GMT
Luigi Bai wrote:

>
>
> On Wed, 27 Oct 2004, Unico Hommes wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Unico Hommes wrote:
>>>
>>>> Now only one release blocker remains: NPE in 
>>>> AbstractEnvironment.release()
>>>
>>>
>>>
>>> No, not exactly. As I see it, ResourceReader should return Source's 
>>> mimeType in this particular case, as per:
>>>
>>>     public String getMimeType() {
>>>         Context ctx = ObjectModelHelper.getContext(objectModel);
>>>         if (ctx != null) {
>>>             final String mimeType = ctx.getMimeType(source);
>>>             if (mimeType != null) {
>>>                 return mimeType;
>>>             }
>>>         }
>>>
>>>         return inputSource.getMimeType();
>>>     }
>>>
>>> But in this case, it was not able to get mime type of the 
>>> SitemapSource. SitemapSource, in its turn, was retrieving mimeType 
>>> from the environment:
>>>
>>> 344:                this.mimeType = this.environment.getContentType();
>>>
>>> But for some reason it is not there. I think that is the problem and 
>>> it was a valid test case for this problem. Unless I am mistaken... 
>>> If I'm not, we should revert the removal of test case.
>>
>>
>>
>> No don't say that! I thought we'd finally gotten rid it. :-(
>>
>> You are right though. My conclusion that the test case was no longer 
>> valid was premature. It used to be that SitemapSource would just 
>> return hard-coded text/xml as its mime type.
>>
>> Anyway, the problem appears to be that the mime-type is only set on 
>> the environment by the processing pipeline during actual processing 
>> whereas at the time Reader.getMimeType is called the pipeline has 
>> only been setup and prepared.
>>
>> Now I am wondering whether we can move setting the mime-type from the 
>> processing stage to the preparation stage. The reason it is currently 
>> being done during processing is that in the case of the caching 
>> pipeline the mime-type is held in the cached response and the 
>> retrieval of the cached response is delayed until the processing 
>> stage in order to optimize performance.
>>
>
> I would like to consider allowing the mime-type to be set during 
> processing, perhaps even as late as after endDocument(). The reason 
> for this is: I store images in XML documents as Base64 encoded data, 
> and its element tag looks like this:
>
> <image mime-type="image/png">Base64data</image>
>
> In this way I can store any kind of image in my files, and it is 
> extracted correctly (I have a Base64Serializer to stream it out). 
> However, in order to correctly extract it, I have to know, in the 
> sitemap, /a priori/, what the mime-type is. Which leads to ugly hacks 
> such as: "You can only put PNG images in this document and JPG images 
> in this document, so I know how to extract them", or perhaps the 
> requester would have to know to ask for a particular mime-type. And 
> adding support for a new image type (admittely this does not happen 
> frequently!) means updating the sitemap and adding new "rules". If I 
> could set the mime-type of the response at least after the pertinent 
> startElement(), then I'd be fine. Of course, that would mean that the 
> response couldn't start streaming until it was "complete" - in this 
> case, setting the mime-type might be the last thing it needs before 
> beginning the stream.


Exactly. This is the problem with delaying the setting of the mime type. 
For the general case we'd always have to buffer the whole response which 
isn't practical.

What you could do instead is to manually set the response header in the 
serializer and make sure the pipeline that processes the response has a 
large enough buffer. You can set the outputBufferSize parameter either 
during the pipe's configuration or using a sitemap parameter.

--
Unico


Mime
View raw message