On Jan 18, 2010, at 13:32 , Fabian Jakobs wrote:
> Hi,
>
> Yesterday I've landed a commit, which adds native JSON support to
> qooxdoo. There is a new class qx.lang.Json, which has exactly the same
> interface as the JSON object defined in the EcmaScript 5 specification
> <https://developer.mozilla.org/En/Using_native_JSON>. All new browsers
> like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it
> natively. In browsers without native JSON support a modified version of
> Douglas Crockford's json2 is used. This is great news because parsing
> and serializing JSON is a lot faster on those browsers.
super good news !!
>
> BUT
>
> we cannot deprecate the old implementation yet. The qooxdoo JSON
> implementation has historically maintained an incompatible JSON
> extension to support dates. The idea was let "eval" create the date
> instances:
>
> qx.util.Json.stringify({ date: new Date(123)}) --> {"date":new
> Date(Date.UTC(1970,0,1,0,0,0,0))}
>
> While it probably was a good idea back then, it is a problem now because
> we cannot make the browser's JSON object emit or parse this:
>
> JSON.stringify{ date: new Date(123)} --> {"date":"1970-01-01T00:00:00.000Z"}
>
> For the server side we have the same problem. If we support this e.g. in
> PHP we cannot use PHP's buildin JSON support, which means a severe
> performance hit.
Another good argument in favor of the ISO string and stick to JSON standard.
>
>
> Since the RPC code is the only code depending on this feature I would
> like to know from the RPC authors:
>
> 1. Wouldn't dates represented as ISO strings be sufficient?
I think, if possible, we should strictly respect the JSON standard.
For our Java backend, an ISO string would be fine, we will be able to convert
from and to that ISO String (or any other) using date formatter.
> Do you think
> we need a special date extension?
I'm not sure about what you are calling an extension, but then, no need for
something special.
> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?
Sure we'll update our future contrib so we'll be able to remove special case in
the json.org code we had to made specific change to it.
The only difficult point is that we are still in 0.8 and I don't know how long
it will take to test against the qx trunk ...
> 3. Do you think everything is fine and we should just keep both JSON
> implementations?
On client side or server side ?
On client side, if we could use the super speed implem, it would be great.
If we want to keep both, we could standardize a meta RPC call where the backend
implem have to return what future RPC call implem will be.
Something where the backend could inform the front end that it is fully
standard or not for JSON date ...
WIthout that call, the default (standard ?) implem will be used. This could
allow retro compatible via only that small addition to the backend.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
