JSON and the cyclical data structures...

[Luke Matuszewski]

Welcome
As suggested i looked into JSON project and was amazed but...

What about cyclical data structures - anybody was faced it in some
project ?
Is there any satisactional recomendation.. .

PS i am ready to use JSON as data/object interchange when using AJAX
and my J2EE project - because it is easier to traverse the JavaScript
object than its XML representation (so of course may argue).

Best regards...
LM

[Luke Matuszewski]

Re: JSON and the cyclical data structures...

As i think more about it a askem myself a question - is there any JSON
extension which does a little more than:
- construction of object as name/value pairs;
- construction of arrays as values;

The extended functionality would be adding JavaScript functions to JSON
implemented in Java and send it to browser javascript code to produce
additional functionality - an object with arrays and functions !

Best regard.
PS probably i will add this functionality in JSON implementation in
Java...

[VK]

Re: JSON and the cyclical data structures...

Luke Matuszewski wrote:[color=blue]
> The extended functionality would be adding JavaScript functions to JSON
> implemented in Java and send it to browser javascript code to produce
> additional functionality - an object with arrays and functions ![/color]

If we're talking Java, let's say it in Java: Remote Methods Invocation
(RMI) technics :-)

JSON is a great idea, but IMHO the author just open the door and
stopped in the door step.

JSON++ (which is indeed badly needed now) should make full reliable
object serialization / deserialization so you could send an object to
server and get it back all filled with needed data.

*** and ***

I guess I'm in the author's kill-files but maybe someone will tell him:
did he ever wondered why so many requests recently about inserting
script from file / changing script src ?

The author is just answering on such requests and asking "Why do you
need it?".

You did not get it yet? People are doing AJAX over <script> using JASON
as the transport media!
People are hitting the stupid "same domain" limitation of
XMLHttpRequest more and more often. It all depends now of the incoming
IE 7.0 / FF 1.5: if the "same domain" limitation will be preserved (and
it looks like that) it may be the beginning of the decline of AJAX and
reuse of JASON++ where the script source handling will be build in into
package itself.
[color=blue]
> PS probably i will add this functionality in JSON implementation in[/color]

You are very welcome ;-)

[VK]

Re: JSON and the cyclical data structures...

I called JSON as "JASON"

My fault:
<http://www.crockford.c om/JSON/index.html>

Definitely a spoiling influence of the American sub-culture (but the
first movie is really cool)
:-D

[Luke Matuszewski]

Re: JSON and the cyclical data structures...

I think that best and easiest way to pass JavaScript function using
JSON and not modifing it is to pass it as name / value pair ... value
would be:
function() {
/* code in JavaScript */
}

and then in JavaScript using XmlHttpRequest do:

var myObjectFromSer verSide = eval(x.response Text);

myObjectFromSer verSide.myFunc1 = eval(myObjectFr omServerSide.my Func1);

Am i correct ?

[VK]

Re: JSON and the cyclical data structures...


Luke Matuszewski wrote:[color=blue]
> I think that best and easiest way to pass JavaScript function using
> JSON and not modifing it is to pass it as name / value pair ... value
> would be:
> function() {
> /* code in JavaScript */
> }[/color]

You did not read JSON right: the whole idea is to have a
platform-independent transport package. JavaScript function is
*JavaScript* function so on the other side have to know how to deal
with it. Array and Associative array structures are universal. So the
caller and the callee do not need to know to what language this
structure appertains to and what syntacs they need to look for / follow
[color=blue]
> and then in JavaScript using XmlHttpRequest do:
> var myObjectFromSer verSide = eval(x.response Text);
> myObjectFromSer verSide.myFunc1 = eval(myObjectFr omServerSide.my Func1);
>
> Am i correct ?[/color]

It is explained on the JSON site (and I tend to believe) that explicit
eval() may lead to some complications. Specially it's true for
serialization / deserialization mechanics

So JSON's stringify(value ) and parse(text) object methods should be
used instead.

And in future I see serialize(value ) and deserialize(tex t) in JSON++
..
..
..
P.S. To whom it may concern: 1) there are all different *array* and
*associative array* in JavaScript and 2) javascript: psi-link may be
used.
But JSON indeed has some great potential I consider to be overlooked.

[Luke Matuszewski]

Re: JSON and the cyclical data structures...


VK napisal(a):
[color=blue]
> It is explained on the JSON site (and I tend to believe) that explicit
> eval() may lead to some complications. Specially it's true for
> serialization / deserialization mechanics
>[/color]

My concept is to generete JSON object (with data in it) on server side
and pass it to XmlHttpRequest (and JSON Java Classes are for it - and
thank to Douglas Crockford i can construct in Java my data structures
and than use toString() method to produce String which be passed to
responseText property of XmlHttpObject then i will do:

var myObject = eval(x.response TexT);

in my function triggered on onreadystate event of XmlHttpRequest.
I can use eval because the JSON site says i can:

http://www.crockford.com/JSON/js.html

<quote>
To convert a JSON text into an object, use the eval() function. eval()
invokes the JavaScript compiler. Since JSON is a proper subset of
JavaScript, the compiler will correctly parse the text and produce an
object structure.

var myObject = eval('(' + aJSONtext + ')');

</quote>

Furthermore one of my properties of myObject would by a String with
function code in it - so to make it function again i would use:

/* myObject.myFunc == "function() { /* some code */ }" */

/* alert(typeof myObject.myFunc == "string") yelds true */

myObject.myFunc = eval(myObject.m yFunc);

/* alert(typeof myObject.myFunc == "function") yelds true */

The restriction is only one - in my myFunc string i cannot use " (but i
can use ' ) as JSON states.
[color=blue]
> So JSON's stringify(value ) and parse(text) object methods should be
> used instead.[/color]

I i want to get a string representation of my object than i would use

JSON.stringify( myObject);

Another issue is when i want to make additional check:

<quote>
When security is a concern it is better to use a JSON parser. A JSON
parser will only recognize JSON text and so is much safer:

var myObject = JSON.parse(aJSO Ntext);
</quote>

Hope you will understand.
BR
Luke.

[VK]

Re: JSON and the cyclical data structures...


Luke Matuszewski wrote:[color=blue]
> Hope you will understand.[/color]

Perfectly, Luke

And the JSON copyright entitle you to do whatever you want as long as:

<quote>
The Software shall be used for Good, not Evil.
</quote>

So you may start realizing your plans right now. If you have some code
ready in the future(and if you decide to keep it freeware) - do not
hesitate to post it here.

[David Wahler]

Re: JSON and the cyclical data structures...

Luke Matuszewski wrote:[color=blue]
> I think that best and easiest way to pass JavaScript function using
> JSON and not modifing it is to pass it as name / value pair ... value
> would be:
> function() {
> /* code in JavaScript */
> }
>
> and then in JavaScript using XmlHttpRequest do:
>
> var myObjectFromSer verSide = eval(x.response Text);
>
> myObjectFromSer verSide.myFunc1 = eval(myObjectFr omServerSide.my Func1);
>
> Am i correct ?[/color]

That's what many people do, but it's not JSON. JSON is a specific
subset of JavaScript's syntax that only has literal structures like
arrays and strings--it doesn't allow arbitrary expressions. The
advantage of this is twofold:

1) A JSON parser is relatively straightforward to write in any
programming language, without requiring it to have a full JavaScript
implementation.
2) You can safely parse JSON without having to worry about security
vulnerabilities . eval() can only be used on data from trusted sources,
because anyone who has access to it can use it to get around the same
origin restriction.

I can imagine situations in which you would need eval() to dynamically
load code from a server, but it's not a great idea for static data,
especially since the JSON library is already freely available.

-- David

[Luke Matuszewski]

Re: JSON and the cyclical data structures...


David Wahler napisal(a):[color=blue]
> 2) You can safely parse JSON without having to worry about security
> vulnerabilities . eval() can only be used on data from trusted sources,
> because anyone who has access to it can use it to get around the same
> origin restriction.[/color]

Can you point how to get around the same origin restriction ? (Can i
use XmlHttpRequest open() URL parameter which is in different origin
(domain) than my script/document when i do it via eval( ) ? )
[color=blue]
> I can imagine situations in which you would need eval() to dynamically
> load code from a server, but it's not a great idea for static data,
> especially since the JSON library is already freely available.
>[/color]

And here you don't understand the concept. JSON site states that when i
have stringified JSON data structure a can use eval to get it back as a
reference in JavaScript so to use it as object/array/string etc.... (i
can also use JSON.parse - but it is slower then eval - and i don't have
to use parse if i know that received data from XmlHttpRequest object is
JSON stringified data structure).

BR.
Luke

[VK]

Re: JSON and the cyclical data structures...


Luke Matuszewski wrote:[color=blue]
> Can you point how to get around the same origin restriction ? (Can i
> use XmlHttpRequest open() URL parameter which is in different origin
> (domain) than my script/document when i do it via eval( ) ? )[/color]

You did not get it totally right because - I have to admit - the
relevant part of JSON docs is ambiguous. It doesn't talk about *that*
eval() from JavaScript. JavaScript eval() doesn't give you any extra
preferences to bypass browser security: neither with XMLHttpRequest,
nor with JSON, nor with any other tools.

But the method with the same name and function presented in many other
languages often used on the server side.

Think for example of a Perl server where you are admin and you have a
JSON module. So you're processing client request like:
eval $JSON_TEXT
and what if $JSON_TEXT contains `rm -rf /` string instead of JSON code?

You may want to check Unix shell commands to see what
eval `rm -rf /`
means to your server ;-)
[color=blue]
> And here you don't understand the concept. JSON site states that when i
> have stringified JSON data structure a can use eval to get it back as a
> reference in JavaScript so to use it as object/array/string etc.... (i
> can also use JSON.parse - but it is slower then eval - and i don't have
> to use parse if i know that received data from XmlHttpRequest object is
> JSON stringified data structure).[/color]

You need to accept first author's understanding of security which is
much wider than just "can I format your drive or not?"

If a text doesn't contain a valid JSON data, eval(txt) will lead to an
error. If you did not put the eval block into try-catch block (or if
it's not supported) then eval(txt) will lead to an uncaught error and
script abort. This *is* a security violation (taking this wider look at
the security).

[Luke Matuszewski]

Re: JSON and the cyclical data structures...

VK napisal(a):[color=blue]
> This *is* a security violation (taking this wider look at
> the security).[/color]
So now i understand... but i only meant to use eval in javascript.

[Lasse Reichstein Nielsen]

Re: JSON and the cyclical data structures...

"VK" <schools_ring@y ahoo.com> writes:
[color=blue]
> I guess I'm in the author's kill-files but maybe someone will tell him:
> did he ever wondered why so many requests recently about inserting
> script from file / changing script src ?
>
> The author is just answering on such requests and asking "Why do you
> need it?".[/color]

And right he is.

There is no reason to extend JSON with a variable assignment, since
Javascript already has that. If you send JSON as a Javascript, e.g.,
by changing the src-attribute of a script tag, you can also extend
what you send with a variable assignment. I.e., send it as Javascript,
but embed the JSON value in it, which you can since JSON is a subset of
Javascript.

That said, I can see a need for an object serialization format that
retains constructors and cyclic references, but that's a different
problem.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Luke Matuszewski]

Re: JSON and the cyclical data structures...


VK napisal(a):[color=blue]
>
> So you may start realizing your plans right now. If you have some code
> ready in the future(and if you decide to keep it freeware) - do not
> hesitate to post it here.[/color]

Can you provide your jsFireReader ? I am interested ;-)

[Douglas Crockford]

Re: JSON and the cyclical data structures...

Luke Matuszewski wrote:[color=blue]
> Welcome
> As suggested i looked into JSON project and was amazed but...
>
> What about cyclical data structures - anybody was faced it in some
> project ?
> Is there any satisactional recomendation.. .
>
> PS i am ready to use JSON as data/object interchange when using AJAX
> and my J2EE project - because it is easier to traverse the JavaScript
> object than its XML representation (so of course may argue).[/color]

JSON, like XML, only serializes trees. Neither handle cyclical
structures directly. It is possible within either standard to define a
metalanguage which could be used to serialize cyclical structures.

This can be useful when persisting complex object systems. It is not
normally useful in the data interchange applications for which JSON is
intended.

https://www.JSON.org