Without knowing all the background let me chirp in.
I still feel strongly that it should be possible to pass a Date in
JSON. I really wish they'd fix JavaScript to have a Date literal form,
and then JSON would likely quickly follow with an update allowing that
form.
For all that I know about Douglas Crockford, I strongly doubt that :).
That ain't gonna happen any time soon, and as much as I think we
should continue to support native Dates, I think moving it to the
realm of "extension" is appropriate. As an extension, the qooxdoo Date
format can remain. *Any other Date format, too, will have to be an
extension.* Dates just can't be sent natively in JSON without special
processing, so a special format must be by agreement between client
and server...
But that is already the case for the existing Date notation, right?! The
'Date' constructor needs special processing. So there doesn't seem to be
a big difference to using a *valid* Json form like
"__new_Date__" : { "type" : "UTC", "coords" : [2009,11,29,3,10,23,973] }
and agree about its processing. But then you had valid Json. Why use
something that breaks Json syntax? And I would expect that translating
this little form back into an internal Date object hasn't much of a
performance penalty.
T.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
