Cool! This class definitely needs more tests and feed-back to be as perfect as possible when 2.0 RC1 goes out.
Cheers, Jerome De : Rob Heittman [mailto:[email protected]] Envoyé : jeudi 11 juin 2009 16:06 À : [email protected] Objet : Re: Re: Re: Last-Modified Header Excellent. I missed that one in the mix of ServerResource newness! I'll try it out on some expensive Representations and publish a benchmark. On Thu, Jun 11, 2009 at 9:23 AM, Jerome Louvel <[email protected]> wrote: Hi Rob, Actually, we did try to facilitate this use case in Restlet 2.0. We introduced the RepresentationInfo class, subclass of Variant and parent of Representation. It contains two properties, modificationDate and tag, necessary for conditional processing. In ServerResource, there are also getInfo() and getInfo(Variant) methods which return RepresentationInfo instances. By default, it calls get() and get(Variant) methods, so it is really an optional optimization. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder~ <http://www.noelios.com/> http://www.noelios.com De: Rob Heittman [mailto:[email protected]] Envoy頺 mercredi 10 juin 2009 19:23 : [email protected] Objet: Re: Re: Re: Last-Modified Header I can't imagine how the framework would be able to figure that out on its own without being able to examine the Representation ... chicken, egg, chicken, egg. Still, I understand the concern if Representations are expensive to generate. I wonder if the conditional logic fetches the entity body if the last modified date has not changed. If it doesn't (and it probably shouldn't) then you could just craft a Representation subclass in which the expensive stuff only happens when the entity body is actually read -- the headers should be enough to tell the engine how to handle the conditional GET. ** disclaimer ** I really don't know if that approach works, but I think it ought to. - Rob On Wed, Jun 10, 2009 at 1:11 PM, Sherif Ahmed <[email protected]> wrote: Cool, This works as you indicate. However implementing this way has a downside. Would be nice that the framework could take care of sending a 304 even without having to get a concrete Representation which has a date set. The idea is to avoid creating a Representation if the Resource has not changed and Restlet could send a 304 directly thus avoiding the cost that may be associated with building a Representation. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361007> &dsMessageId=2361007 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361307
