I would like to comment on the date/time marshalling because a while back I had a similar problem in Python XML-RPC.
There seem to be two issues:
1. How to "tag" data to indicate it's a date
2. Deciding on the string format which represents the date
ad 1.:
Dates seem to be such a common type of data that they deserve "special treatment" as part of the standard, but they're not getting it. It's my understanding that this is underway.
Obviously, as long as there is no standard in JSON, you would need to invent something with the risk of becoming incompatible later. Have a look at these thoughts: http://www.nikhilk.net/DateSyntaxForJSON.aspx
In my opinion, class hinting seems to be too implementation-specific and stay reserved for your "own" objects, not dates.
I like the idea of enclosing dates in "@" characters as a convention. I would vote for that unless a different standard is already planned (I couldn't find anything).
ad 2.:
First of all, whether seconds or milliseconds since epoch, both your approaches lack timezone information! That means you need to assume one (like UTC) and "lose" the original.
Secondly, what about things that happened before 1970, like say a birth date in a data entry form? Not uncommon. Please give those old people a chance. :-)
There are standards (based around ISO8601):
W3C Date and Time format: http://www.w3.org/TR/NOTE-datetime
RFC3339: http://www.faqs.org/rfcs/rfc3339.html
Why not stick with that?
So in combination there could be an object value of
@1969-04-12T23:20:50.52Z@
which solves a) and b), is human readable, and I believe you can throw this (without the enclosing @'s) at Date()?
It's certainly easy to parse (on both sides), see the source for http://mochikit.com/doc/html/MochiKit/DateTime.html#fn-isotimestamp and http://mochikit.com/doc/html/MochiKit/DateTime.html#fn-toisotimestamp
Hope I was constructive here. :-)
Kind regards,
Danny
On 6/14/06, Andreas Junghans <[EMAIL PROTECTED]> wrote:
Hi Derrell,
Am 13.06.2006 um 13:52 schrieb [EMAIL PROTECTED]:
>>> 1. It requires that the JSON server/peer be implemented in a
>>> language
>>> that
>>> provides a Date object.
>>
>> Not really. It only means that a theoretical server without such
>> objects
>> (which I find hard to imagine) cannot exchange dates with the
>> _javascript_
>> side. This problem is the same no matter how the date is encoded.
>
> Hi Andreas,
>
> These were real-life problems I encountered. PHP has no Date
> object. It has
> all of the functions necessary for dealing with dates, but no Date
> object.
OK, so there's no explicit date object, but there's still a
meaningful conversion from a _javascript_ date to a PHP representation
(seconds since the epoch or whatever).
>>> 2. It requires that the JSON server/peer be implemented in a
>>> language
>>> that has a "new" operator.
>>
>> No, it doesn't. The "new Date(...)" notation has the one and only
>> purpose to
>> make server responses "eval()-able" and get real _javascript_ date
>> objects. Just look at the Java side: "new Date(...)" is parsed as
>> a string,
>> not evaluated or anything.
>
> Very true... when it's *received* at _javascript_. When *sending* a
> date to the
> server, "new Date(...)" can't be parsed directly if the server is
> not written
> in a language that knows of such a thing. PHP is one such server.
To repeat: The Java implementation also doesn't evaluate the "new Date
(...)" construct directly (as there's no eval() in Java). The
notation could as well be something like "makeMeANiceObject:date
{...}", and the Java implementation wouldn't care (apart from
adjusting two strings). The notation is directly taken from
_javascript_, and it's not expected that _any_ server can parse it
directly. Same for the rest of the JSON syntax: I don't know any
server that can work with it directly, it all has to be parsed (more
on that below).
> Worse yet,
> if the server were written in C, there are no objects at all in the
> language.
> They would be simulated with structures.
Or a date could simply be represented by an integer or float value,
but that's not the point. What's important is that it's easy to work
with in _javascript_, as this is the slow part.
> Communications protocols really
> should not include language constructs. JSON was implemented as a
> language-
> independent communication protocol that can do what we need. I
> feel pretty
> strongly that putting language constructs into the low-level
> protocol is
> inappropriate, assuming an alternate method can be found to do it
> as the
> protocol intends.
JSON uses a _javascript_ subset, and that's not a coincidence.
Implementations in all other languages must parse the _javascript_
syntax instead of simply eval()-ing it. The "new Date(...)" construct
is just an extension of the subset by one additional element. The
downside is that it's not part of the JSON standard and that it looks
more language-dependent than [, :, {, etc.
>> Like the server environment without some kind of date object, I
>> find it hard
>> to imagine a language/runtime without 32-bit integer support.
>> Even then,
>> the number could still be parsed and converted to a date (just
>> like 32-bit
>> languages can handle arbitrarily long numbers, just not as a native
>> datatype).
>
> Ah, you misinterpreted me. The problem isn't a lack of 32-bit integer
> support, it's a lack of 64-bit (or at least greater than 32-bit)
> integer
> support. PHP had to convert those large integer values into
> floating point
> because they don't fit in a _signed_ 32-bit integer (they may fit
> in unsigned,
> but in PHP, the programmer isn't able to specify that). Therefore,
> if I sent
> a Date object to the server and immediately echoed the Date object
> back to the
> client, the client received different data than it had sent. Bad.
Ah, OK. Sorry for the misunderstanding, my bad (milliseconds are
certainly too large for signed 32-bit ints). However, even seconds
are too large for that, at least if you want to be able to represent
dates beyond 2038. But anyway, what is actually sent across the wire
is just a string, so any server should be able to parse it (either
with or without storing it in some kind of 32 or 64 bit variable
while doing so).
>> I don't really like the use of _fixObj. Recursively examining the
>> whole
>> response can be quite time-consuming for complex structures.
>
> I figured this would be the primary point of contention. I wonder
> if I can
> provide a property which lets the implementation know whether fixObj
> () is
> required. If the application knows that no dates will be sent, it
> can disable
> that feature (or maybe, have it default to 'off' and allow the
> application to
> enable the feature if it knows that dates will be sent).
Even with this switch, applications that use dates would be penalized
for it. They would either have to implement their own date handling
or let _fixObj iterate through the whole structure, even if there's
only a single date somewhere.
I don't have anything against class hinting, but I see it as a layer
above the "normal" objects (maps, arrays, strings, numbers, and -
arguably - dates). To be useful, I think class hinting has to be
generic: It must include the class name and the constructor
parameters, as described in the JSON-RPC spec. What you propose is
just a special construct for dates (with specific fields that the
server must know about). It has to be specifically implemented in all
server backends, similar to the "new Date(...)" syntax.
To summarize, I see these advantages of your solution:
- It conforms to the existing JSON syntax specification.
- _javascript_ dates could at least be passed around on servers that
don't understand the syntax, even though they wouldn't carry semantic
meaning.
- Extensible (although I think that a general class hinting mechanism
should work with constructor parameters and their order, not with
names).
These are the positive points of the "new Date(...)" syntax:
- Fast parsing in _javascript_.
- Easy to parse on the server-side: "new Date(" is a hard prefix, ")"
is a hard suffix - no need to introduce a general concept of a new
operator.
I don't want to treat dates as objects - I was just looking for a
syntax that _javascript_ would understand directly (similar to quotes
for marking strings) and that other languages could easily parse.
This isn't meant as a general "new XYZ()" syntax for alls kinds of
classes - class hinting is just fine for that. IMHO Date is different
from other objects because it's a _javascript_-builtin, and the servers
have to adjust for that. (Similarly, C and other languages don't have
associative arrays, but they're still part of the JSON syntax, so
thay have to deal with it.)
OK, enough rambling :-) I don't mean to bash your solution, and you
have good points. I just want to make it clear where I'm coming from
and what my concerns are.
It would be great if you could do some performance tests with both
implementations. If _fixObj works reasonably fast with big responses
(say 8K or so), I'd have much less trouble with your solution.
>> In summary, I'm not convinced your Date changes make the
>> implementation
>> better. Using some kind of class hinting may be conceptually
>> cleaner, but I
>> don't like the additional client side overhead. Maybe we can hear
>> some more
>> opinions?
>
> Now that I've better explained the reason for separating seconds
> and ms, I
> hope you are more convinced. Thanks for your comments!
> Collaborative work
> tends to generate the very best implementations!
Agreed! What are the opinions of others out there?
Regards,
Andreas
PS I'm subscribed to the qooxdoo-devel list, so no need to send mail
directly to me.
--
Dipl.-Inform.(FH), M.Sc . Andreas Junghans
STZ-IDA an der Hochschule Karlsruhe
email [EMAIL PROTECTED]
internet http://stz-ida.de
telefon ++49-721-920-3302
fax ++49-721-160-890-56
Moltkestrasse 30, D-76133 Karlsruhe/Germany
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Danny W. Adair
Director
Unfold Limited
New Zealand
Talk: +64 4 472 1679
Fax: +64 4 472 1680
Write: [EMAIL PROTECTED]
Browse: www.unfold.co.nz
Visit/Post: 22a Clifton Terrace, Kelburn 6005, Wellington, New Zealand
_______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
