Hi Derrell,
As I stated, my intention was not to be disruptive. Your response is
appreciated, and I'm happy to leave things as they are right now, if
that's the feeling of the team. You make a great case for not upsetting
the status quo. Of course, I understand the reason for defining any
special date handling as an "extension" instead of a "standard" feature,
since nothing we do with dates will be standard JSON due to a lack of
ANY standard for dates.
Actually, I think that even the epoch date format is still a string of
one kind or another, with the epoch number embedded within a string
wrapper to distinguish it as a date rather than just a really big
number. The implementations I saw in my searching either embedded the
epoch milliseconds between starting and ending text markers ("@") or
within a "Date(...)" text wrapper. In all of these cases, a JSON parser
needed to detect that the value was a date string and then perform the
necessary conversion, as you pointed out. In the Qooxdoo method, I'm
guessing you pass all JSON values through an "eval" statement and use
whatever comes out of it, right? The Date constructor string value
generates a native date format in the client variable, quickly and
efficiently without the need to "recognize" that it's a date value. I
get the benefits of that method!
At any rate, if the core developers feel strongly about using the
current format in Qooxdoo, then I'm ok with just getting back to coding
my RPC and not worry about it.
Thanks for your insight - I appreciate it.
Gene
On Tue, 2009-12-01 at 23:08 -0500, Derrell Lipman wrote:
> On Tue, Dec 1, 2009 at 10:35, Gene Amtower <[email protected]> wrote:
>
> Team,
>
> I've been researching the JSON Date problem a bit, and I
> wanted to share some information from my web research. Since
> I'm working on an Oracle RPC backend, I'd like to design and
> develop it once, so I'd prefer to sort this out before doing
> the heavy lifting in my development.
>
> It is clear to all that the JSON standard does not offer a
> standard method for dealing with dates, beyond the fact that
> they are to be represented as a string in whatever form the
> developer chooses. This leaves developers with a myriad of
> choices for handling JSON dates. IMHO, Qooxdoo developers
> have chosen a string format that is uniquely different than
> anyone else's chosen format, likely chosen before any
> established practices began to surface in the industry. So,
> no fault is intended towards the Qooxdoo development team.
> However, I wonder if it's time to consider using a more common
> approach to JSON dates in order to align with other
> development environments, although I recognize that it may
> have downsides to Qooxdoo developers, especially WRT backwards
> compatibility.
>
>
>
> The format used for JSON dates by qooxdoo was selected for one
> specific reason: it is fast for the client side to parse dates back
> into Date objects. Any other format requires deciding (at some point,
> either while parsing, or by the user's application) that the string or
> numeric value is in fact supposed to be a date, and doing a
> conversion. The format we use is FUGLY. We've always known that, and
> Andreas Junghans and I debated this for a LONG time many years ago,
> trying to find a solution that yielded both a conformant JSON string
> AND a format that yielded a Date object if what was sent by the server
> was intended as a date. The JSON spec used to (and may still) have a
> mechanism for providing type hints. Both Andreas and I felt it was too
> inefficient.
>
> Without special date processing, there is no way to pass a date from
> the server to the client and have a Date object created automatically.
> Therein lies the big problem. JavaScript neglected to include a
> literal form for the Date object. It is the ONLY native object for
> which no literal form exists. This is the root of the problem. Any of
> these other formats being discussed, ISO8601 or milliseconds since the
> epoch, will end up at the client as a string in the former case, or a
> number in the latter case... not as a Date object which is really
> what's desired. The user application will have to convert it.
>
> 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. 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... or the client and server should just do no special
> processing. In that case, dates will be passed as a number or as a
> string, and only converted to a date by user code (at each end) that
> knows that the string or number actually represents a date.
>
> 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
------------------------------------------------------------------------------
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
