Chuck Hinson wrote:
First, I'm not sure I understand why you'd call getEntityAsForm() if
the params are in the URI.
I was using it on the client side to get the Response.
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.
Yes, but they where talking about the implementation caching it, at
least that's the option I think you'd have to use. As like you said it's
streamed from the socket. Then what I asked was isn't using DOM the same
a caching it into memory. As you said, what if it's a large DOM. Which
then lead me, and others to say why is getEntityAsxxx() even in Restlet
API.
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.
There are many caching implementations that could make use of a
memory/disk based cache.
Finally,I'm in agreement with Rob's later message - this
getEntityAsXXX() stuff really belongs outside of the Message/Request
classes.
Agreed.
--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]
<mailto:[EMAIL PROTECTED]>> wrote:
Thierry Boileau <thboileau <at> gmail.com <http://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.
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
