WD1.1, Ch 13, Limitations.

The Spec says:

>  It is worth noting that JSON-RPC is limited by the
inability to  
> represent cyclic object graphs in JSON text. Therefore 

> implementations SHOULD take care that parent-child,
sibling and  
> cross-reference relationships result in error at the
client end  
> when making the remote procedure call or server end
when responding  
> with the result of the call. There are two possible
ways to control  
> this:
>
>     * Configure a maximum allowed size of the request
and response  
> messages produced for a remote procedure call.
>     * Configure a maximum depth of nesting of Array and
Object values.
>
> As soon as either configured limit is breached, the
client or  
> server fail the call with an error.

Cycles are fairly easy to detect.  Traverse the graph depth
first  
from the root node, and keep a stack of  nodes along the
path from  
the current node to the root. If you visit a node that is
already on  
the stack, you've found a cycle and can throw an error
immediately.

Of course, this requires that you can compare two objects
for  
identity rather than just equality, but it is a much better
solution  
than configuring a maximum size.

Maybe spec should just specify what error to return when a
cycle is  
detected, since any JSON serializer should be doing cycle
detection.

eric.




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups
.yahoo.com/group/json-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://gr
oups.yahoo.com/group/json-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:json-rpc-digest@yahoogroups.com 
    mailto:json-rpc-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    json-rpc-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/
 

Am 13.02.2007 um 19:33 schrieb Eric Busboom:

> Maybe spec should just specify what error to return
when a cycle is
> detected, since any JSON serializer should be doing
cycle detection.

A decoder can not know wether a request/response is just big
and  
deeply nested or if the sender tries to encode a cyclic data
 
structure: within the bounds of memory available to the
decoder both  
cases would look alike.

Anyways, the decoding application would have to shut down
the input  
stream and report, a server probably should report a
malformed request.

Ciao
   Andi



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups
.yahoo.com/group/json-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://gr
oups.yahoo.com/group/json-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:json-rpc-digest@yahoogroups.com 
    mailto:json-rpc-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    json-rpc-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/
 

On Feb 13, 2007, at 2:34 PM, Andreas Hofmeister wrote:

>
> Am 13.02.2007 um 19:33 schrieb Eric Busboom:
>
> > Maybe spec should just specify what error to
return when a cycle is
> > detected, since any JSON serializer should be
doing cycle detection.
>
> A decoder can not know wether a request/response is
just big and
> deeply nested or if the sender tries to encode a cyclic
data
> structure: within the bounds of memory available to the
decoder both
> cases would look alike.
Since a cycle is, well, cyclic, the case you are describing
her would  
be that the encoder followed the cycle until it ran out of
memory,  
and then just sent whatever encoded data it had at the point
it  
terminated. That is clearly not a good representation of the
original  
data structure, and should not be sent. Detecting cycles is
an  
encoder's problem, and should be done as soon as possible,
since if  
your encoder does not terminate at the moment it finds a
cycle,  
running out of memory ( or hitting a memory limit )  is
inevitable.  
It would be incorrect to do anything but fail as soon as
possible.

Since JSON does not have references and can't encode a
graph,  cycles  
can only be a concern for the encoder.  The decoder can't be
 
concerned with whether the encoded data structure is a
proper  
representation of the source data structure, only that is it
well- 
formed JSON.

Running out of memory during decoding is a different problem
that  
must be handled for any case where the data is
extraordinarily large.  
It is not specific to the problem of cycles.

eric.




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups
.yahoo.com/group/json-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://gr
oups.yahoo.com/group/json-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:json-rpc-digest@yahoogroups.com 
    mailto:json-rpc-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    json-rpc-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/