Jerome Louvel wrote:
>> 1 works really well for the case when returning say FileInputStream
>> or File but if say you have to return a Feed instance containing 100
>> Entry instances transformed from a DB query only for it never to be
>> serialized then it can be a waste of CPU for the web container and
>> the database.
>
> Note that if you return a File instance as a representation POJO, the JSR
> implementation should be able to transparently wrap it and expose the
> obvious metadata like the media type, size, the last modification date or
> the expiration date.
>
Good point, a 'streaming provider' for File could do this. Also in the
case of File it may be possible for the runtime to perform asynchronous
writing (essentially tell the kernel to do the writing). Not sure if
that is possible today with NIO though... but would be cool to do :-)
Do you think File should be a supported type for this JSR?
>> The API proposal currently specifies support for 2 (via precondition
>> checking on the request context and returning HttpResponse), but it
>> did not occur to me that we could also support 1, which is nice :-).
>> 2 also allows for extended precondition support.
>>
>> Paul.
>>
>> * This is another use case in favour of reusing Representation<T> as
>> opposed to mandating that developers modify T or wrap T in their own
>> class.
>
> Why do you need a specific support for 2) in the API?
Ease of use, development, maintenance, readability.
> It would be easy to
> create a custom Representation<T> subclass that would carefully optimize the
> access to the wrapped T instance.
>
I agree it can be done but IMHO it is unnecessary work for developers.
We can make it easier for them.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109