cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bai <lpb+coc...@focalpoint.com>
Subject When to set mime-type (was: Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater )webapp/samples/test/reader-mime-type
Date Wed, 27 Oct 2004 14:19:37 GMT


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.

What would this mean for caching? For me, it means the mime-type *cannot* 
be part of the cache-key, since it cannot be known a priori. However, it 
does have to be cached with the document.

> Is it really neccessary or desirable to cache the mime-type? What happens if 
> the effective mime-type is from the  one from the reader definition or the 
> read node declaration (<map:reader class=".." mime-type="text/xml"/> or 
> <map:read src="somewhere" mime-type="text/xml" />) From these examples it 
> follows that the mime-type must be part of the cache-key because if you were 
> to change it in any of the attributes above the previously cached contents 
> should not be served.
>
> Btw. ResourceReader.getMimeType() method above looks a bit funny to me. The 
> mime-type mapping from the context has priority over the mime-type of the 
> individual source. Surely that should be the other way around?
>
> Comments?
>
> --
> Unico
>
>

Mime
View raw message