On Wed, Dec 2, 2009 at 03:55, thron7 <[email protected]> wrote:
> 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.
>
No. That's the "beauty" (if one can find any beauty in this mess) of the
current format. No special processing is required at the client side. The
current format is eval()'ed and automatically generates Date objects. You
don't need to convince me that it's both ugly and non-conformant, but it
does have this one significant (Andreas and I thought) advantage over any
other possible format.
Derrell
------------------------------------------------------------------------------
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
