Paul,
[...]
> Perhaps we need two solutions for the following cases:
>
> 1) returning Representation<T>*; and
>
> 2) when creation of T is costly but obtaining the etag and/or last
> modified is relatively cheap.
>
> 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.
> 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? It would be easy to
create a custom Representation<T> subclass that would carefully optimize the
access to the wrapped T instance.
Best regards,
Jerome