[Json-rpc-java] Fwd: Callable references in a map

[Raziel Alvarez]

Merging this solution as is won't be backwards compatible in the first
place: obviously we'll have to replace evals with the new evalJSON (since
evalJSON won't eval a "regular/standard" JSON object), and now toJSON won't
return what it used to; yes, it is a strictly formatted JSON object but not
the object I passed to be translated (then this function should change the
name, because it would be misleading). For example, I currently use the
toJSON function to translate JS objects to JSON format and store them in
files (lightweight, efficient option to XML). Thus, I'd have to create a new
separate toJSON function for this purpose.

I also don't like the idea of forcing everybody to add this extra complexity
for a feature that, even though useful, certainly is not required all the
time.

Finally, I think changing the way we use JSON format is a huge change that
will deviate this tool from the standard (doesn't sound like a good idea to
me). Would it be still called JSON-rpc?

Again, if this can be added in some other non intrusive way it would be
really nice.

Regards,

On 8/6/07, William Becker <wbecker at gmail.com> wrote:
>
> Hi,
>
> The thing about Javascript is it can normally can handle circular
> references. If you are using firefox, go to the error console and
> evaluate:
> "a={};b={};a.x=b;b.x=a;a.y='a';b.y='b';a.toSource()".
>
> You should find the output is: "#1={x:{x:#1#, y:"b"}, y:"a"}"
>
> You can then say "a=#1={x:{x:#1#, y:"b"}, y:"a"};a.toSource()" and the
> output should again be #1={x:{x:#1#, y:"b"}, y:"a"}.
>
> The problem with this, is it is most definitely not JSON. JSON is only a
> subset of Object Literal notation and only seems to handle numbers,
> strings,
> booleans, arrays, objects and nulls.
>
> What I ended up doing was detecting all objects within a javascript object
> and putting them all with unique ids in a javascript object. So my code
> does
> produce strict JSON: it is just that the JSON I produce is not immediately
> able to be assigned to a variable with the eval() function. Instead there
> needs to be something that deconstructs it, because the circular reference
> format sits on another layer above the base JSON.
>
> Now if this were to be used in JSON_RPC we need to ask, does it matter
> that
> eval cannot be used directly? Why do we need to use eval? Why do we need
> to
> use JSON in the first place? In answer to the latter, I assume that it is
> only because it is a standardised message format that is relatively terse
> compared to XML. It isn't because we are trying to have other programs
> drop
> in on our messages. So, why do we use eval? Because it is convenient and
> (we
> hope) fast. My evalJSON function (I'll attach just this and the
> JSONSerializer - it should be able to get under the size limit) does call
> eval on the string returned, it just looks through it to see if there are
> any other objects that need to get pulled in: it should be O(N) where N is
> the number of objects being sent. So does it matter that we do not use
> eval
> directly? I can't think of a compelling reason.
>
> Now the other question raised was whether we could just check to see if
> the
> code had circular references or not. I'm sure we could, but it will mean
> that we have additional overhead: to do this we have to check if there is
> a
> circular reference and this would make the code more inefficient, since
> the
> way the code works is that it just puts all objects into a superobject
> with
> an id for each: this check isn't in there at all. You would have to go
> through each object anyway, generate a hash each object's inner objects,
> recursively. Then when this is done, you need to next determine if for any
> of these objects, an object contains another object which contains itself.
> It seems like there maybe a high complexity attached to that, but it works
> for both java and Javascript marshalling. The other way is to do it
> normally, see if an exception is thrown (on the server side) or see if it
> produces scrambled javascript (on the client side) and only then do it.
> That
> may be a better option but it will mean that it is slower. Perhaps a
> better
> way would be to combine the two and allow a user to specify a setting so
> that if they want they can have it try to do it an exception based way if
> the majority of their code will be acyclic, otherwise they can specify
> that
> it should always assume it is cyclic and stop that check.
>
> This seems to be what Arthur is suggesting below. Considering we have both
> come up with the same idea, maybe this would be a good course of action! I
> would love to get this merged in so I can get back to using the main
> trunk.
>
> Cheers,
> Will
>
> _______________________________________________
> Json-rpc-java mailing list
> Json-rpc-java at oss.metaparadigm.com
> http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
>
>
>