First, I'm not sure I understand why you'd call getEntityAsForm() if the params are in the URI. Second, this really doesnt have anything to do with REST - it has to do with network communications. When you're recieving data from a socket, once you've read the bytes, you can't put them back. As far as caching goes, my experience is that it is hard to implement in a meaningfully general way that doesn't kill performance in any non-trivial system. First off, some messages can be really large and you'd rather stream them directly to a file rather than trying to cache them in memory. Secondly (and probably more important), you don't generally know ahead of time how big the incoming entity is, so you can't efficiently allocate memory. Finally,I'm in agreement with Rob's later message - this getEntityAsXXX() stuff really belongs outside of the Message/Request classes. --Chuck ________________________________
From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 10:12 AM To: [email protected] Cc: [email protected] Subject: Reusable representations (Changed subject line to reflect drift) Adam and I were discussing this at our shop yesterday ... One of the issues I have seen bite Restlet newbies is that Form is the idiomatic path to access query string parameters and such, but getEntityAsForm() consumes the request. If someone calls getEntityAsForm() in, say, a Guard, to look for an authentication token on the URI, a downstream Restlet trying to get the representation will fail and this results in puzzlement. Now, it is not good REST to mix a function call paradigm with representational state transfer in the same call; while it is a common Web practice to glue query string parameters onto an unrelated representation as a signalling mechanism, this is not RESTful, and it is probably good that the NRE discourages this. Notionally, a single HTTP operation transacts a single representation, and that representation should represent a single thing. But I think it would be perfectly fine, however, if getEntityAsForm() and getEntityAsDom() could be called repeatedly, and subsequent calls against the same Entity would simply retrieve a reference to the Form or DomRepresentation created in the prior call. This neither encourages sloppy REST nor breaks scalability. The relevant in-memory objects have already been created and will go away when the request completes. While the underlying representation types (e.g. StreamRepresentation or SaxRepresentation) are indeed transient, the Form and DomRepresentation actually represent a completed in-memory parse of the underlying transient representation ... and need not be transient themselves. So this would work: Form form1 = request.getEntityAsForm(); String f1s = form1.getFirstValue("foo"); Form form2 = request.getEntityAsForm(); // just returns another reference to form1 String f2s = form2.getFirstValue("foo"); // should not throw an exception While you might no longer be able to access the original entity or a /different/ Representation after calling one of these methods, there's no reason that a number of Restlets in the same chain, needing to operate on a Form or DomRepresentation, actually need to implement their own private caching mechanism. We already have some fairly long chains of Restlets using components that are supposed to be pluggable and interoperable; the less they have to be aware of each other the better. I haven't looked into a patch yet, but I can't imagine it would be tragically complex. Thoughts? ----- Original Message ----- From: "Thierry Boileau" <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, August 28, 2007 2:59:36 AM (GMT-0500) America/New_York Subject: Re: Custom gaurds Hello Alan, well, you're right, Jerome could have define Representations with some caching system allowing to get content anytime we want. I think that Jerome had made the design choice that : - gives you the lighter and cheaper way to use transient representations, when you read them once (which is a basic but probably the most frequent case, I think) - let you free to simply and transparently convert a transient representation to a StringRepresentation (or any kind of self defined representations) for example in case you want to read it several times which means unavoidably that the content is "stored" in memory, in a file, etc. best regards, Thierry Boileau On 8/27/07, Alan <[EMAIL PROTECTED]> wrote: Thierry Boileau <thboileau <at> gmail.com> writes: > > Hi, > > This "limitation" concerns the following representation classes (and > descendants included in the Restlet API and NRE) : > Ok, for my clarification: the "limitation" is due to the implementation of the NRE library, not a limitation of the http model? In theory, an implementation could do something like cache the initial input source to make subsequent calls to getEntityAsFoo work. Is there a reason for this? Looking at the source I saw that it is possibly due to the fact data is read off a stream of unknown length and caching request data may be prohibitively expensive? By the time the server is processing the request is the client pipe closed? (I guess I'm thinking about something like continuations). I'm just curious, I have no plans to offer another implementation :) I suppose I'll need to rethink my implementation if I wish to make restlets behave in an filter/guard agnostic manner. By the way, this is a nice paradigm, I much prefer it over servlets. thanks.
