A response reset will only work if the response hasn't been committed
yet.
And after outputting 200 resources in JSON format, I guess it will
have been committed already?
Simon
On 13 Jan 2010, at 10:18, Ian Boston wrote:
On 13 Jan 2010, at 08:54, Felix Meschberger wrote:
Hi,
First off, I think scanning the (sub-)tree twice (once for checking,
once for sending) is not a good idea performance-wise anyway.
Put this aside, the check-part could scan breath-first, keeping
record
of the number items visited after each level. As soon as the
threshhold
as been reached, the maximum supported level is known.
The rendering-part can then use the level to actually render the
data,
which is done in a depth-first manner.
We might be able to combine the two approaches, by building an in-
memory
representation of the JSON data (JSONObject) and when the threshold
has
been reached, just serialize the JSONObject.
I think 2 runs only becomes relevant if you want to adjust some of
the response (like the response code), since this doesnt look
sensible, a simple response.reset() might be better (does that
always work?) when the limit is hit.
Ian
Regards
Felix
On 13.01.2010 00:51, Simon Gaeremynck wrote:
Ok,
Is the following approach better?
Consider node.10.json
Check if the response will contain more than 200 nodes
If so, proceed with the way it is now and send the resources along
with
a 200 response code.
If it is not,
Check if node.0.json results in a set bigger then 200 nodes.
If not check node.1.json, then node.2.json, ...
Basically, keep increasing the level until the number of resources
is
bigger then 200.
This would give the highest recursion level you can request.
The server would then respond with a 300 and (I think?) a header
'Location' with the highest level.
The thing off course is that you would have to loop over all those
nodes
again and again.
Jackrabbit will have caches for those nodes but I'm not really
sure what
the impact on performance would be.
Simon
On 12 Jan 2010, at 00:53, Roy T. Fielding wrote:
On Jan 11, 2010, at 10:01 AM, Simon Gaeremynck wrote:
Yes, I guess that could work.
But then you can still do node.1000000.json which results in the
same
thing.
I took the liberty to write a patch which checks the amount of
resources will be in the result.
If the result is bigger than a pre-defined OSGi property (ex: 200
resources) it will send a 206
partial content with the dump of 200 resources and will ignore
the rest.
It can be found at http://codereview.appspot.com/186072
Simon
Sorry, that would violate HTTP. Consider what impact it has on
caching by intermediaries.
Generally speaking, treating HTTP as if it were a database is a
bad design. If the server has a limit on responses, then it
should only provide identifiers that remain under that limit
and forbid any identifiers that would imply a larger limit.
An easy way to avoid this is to respond with 300 and an index of
available resources whenever the resource being requested would
be too
big.
The client can then retrieve the individual (smaller) resources
from
that index.
....Roy
