Hi Derrell, Am 15.06.2006 um 04:00 schrieb [EMAIL PROTECTED]:
> What I ended up doing was using the ISO-8601 format for > transmission *to* the > server. It's currently encapsulated in a "new Date(<iso_8601 > string>)" but > possibly needn't be. There does need to be something that > identifies it as a > Date object, so maybe this encapsulation is as good as anything. > > For communication *from* the server back to the client, either of > two formats > should be used (the choice being left to the server): > > new Date(msSinceEpoch) > > as is done in the Java server implementation, or > > new Date(Date.UTC(year, month, day, hour, minute, second, ms)) > > as is now done in the PHP sever implementation. I would greatly prefer a single, standard format, no matter in which direction a date is sent. Originally, I would have voted for the first method (milliseconds). However, I took a look at the PHP date functions, and they truly suck! Everything timestamp-related suffers from the 2038 problem on 32-bit machines - but you can't even calculate time differences without resorting to timestamps! Since it's so difficult to properly handle timestamps in PHP (and maybe other backends too), I suggest we standardize on the second syntax: new Date(Date.UTC(...)). More comments on that below. > These are the only two reliable mechanisms to send to an arbitrary > javascript > client. Very unfortunately, the javascript authors didn't define > the strings > that Date.parse() must allow, so there is no standard-format string > that can > be sent from server to client as "new Date(<string_representation>)". > > My requirements for the implementation were: > > - the format sent to the client must be directly eval()able. > > - millisecond (at least) precision must be supported, and handled > easily at > any server that provided only 32-bit signed integers. This > excluded using > the IETF date format string that Date.parse() on Firefox > accepts, and > excluded using the msSinceEpoch since distant past or distant > future dates > could overflow a 32-bit integer even with just seconds (and > "parsing" the > integer value is too much work -- see the next requirement). The UTC syntax supports ms and should work in both directions. > - the format received at the server must be very easy to parse in > a variety > of languages. I think it should be fairly easy to parse the UTC syntax (comma- separated numbers). If it saves a lot of coding, we can restrict the syntax to not allow spaces. Backends like PHP can choose to ignore the milliseconds when receiving and not add them when sending. I think the comma-separated format should be easy enough to parse in PHP using strptime (at least if we disallow spaces). I don't know exactly how strptime works - it may be necessary to manually cut off the millisecond part before calling strptime (e.g. by counting commas and extracting a substring). > - it must be possible to send an arbitrary Date object from the > client to the > server, have the server convert it into whatever internal type > it desires, > echo it by converting it back to JSON and sending it back to the > client, > and by comparing the sent and received Date object at the > client, have an > identity relationship. > > I've also fixed a few bugs identified by Sebastian, and added a new > Date test > in the PHP server, to retrieve the current timestamp (to 1-second > precision, > for now). > > I hope this revision eliminates everyone's problems with the first > version. > Please send comments. After I hear (particularly) from Andreas J > that we've > come to agreement, I'll check this in to svn. What do you think about standardizing on "new Date(Date.UTC(...))"? If you agree, do you think it's necessary to disallow spaces around the commas? I can change the Java implementation accordingly. > BTW, I wanted to document the reason for using new Date() in the > code. My > comment turned into a small book -- enough that I had to split the > comment > into parts for the script that generates qooxdoo.js to not barf :-) > but at > least others won't have to go through the same "WTF" head- > scratching that I > did. See Json.js. Good idea! I've now had a chance to look at your other changes and have a few comments: 1.) You eliminated the instanceId parameter (at least in its previous form). It seems you have confused it with an id for a single call, but that's not the intention. The purpose of the instanceId is that you can use it to talk to a single object instance on the server over multiple calls (as opposed to getting a new or random instance every time). On the other hand, you can have multiple service instances in the same session, each with its own status data. I have no problem with adding a call id, but please leave the original instanceId functionality in! 2.) I don't like the synchronous call warning. You could as well issue a similar warning in the asynchronous case because it's so easy to get asynchronous communication wrong. Sometimes it's just necessary to make a truly synchronous call to preserve application semantics. For example, when you commit some changes to a database entry, and continuing in your application requires that the server validated and stored the changes, there's just no way around a synchronous call. A strong warning should be present in the API documention, but adding obnoxious log messages is a sure way to alienate developers. However, I'm open to other opinions. If a majority thinks that the warning is a good idea, I can live with that. 3.) You removed the use of qx.core.ServerSettings and replaced it with a URL that must be specified. This is fine, but there has to be at least a helper method to construct a URL to the server application where the current page came from. I can add the necessary code myself, so don't let this point prevent you from checking in. If you're interested, I can explain why I think such a mechanism is necessary. Thanks again for your contributions, they're very welcome! Regards, Andreas _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
