Andreas Junghans <[EMAIL PROTECTED]> writes: > I would greatly prefer a single, standard format, no matter in which > direction a date is sent. > ... > 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.
I would have a slight preference to use the same format in both directions, but I found that I'd have to entirely rewrite the JSON parser in PHP to use this alternate format. The current one uses commas as a separation point at a level that is not easily modifiable, so getting the entire "DATE(Date.UTC(x,y,z...))" as a string for easy parsing isn't part if this parser's design . I'm *really* not eager to rewrite a JSON parser. The format I selected is so incredibly easy to parse that any server should be able to deal with it. That's why I switched to it. I also think it makes a lot of sense to leave it to the server to select one of the two supported output formats (msSinceEpoch or Date.UTC) since different server implementations will want to internally maintain one or the other. The Java and PHP implementations are a good example. > I think it should be fairly easy to parse the UTC syntax (comma- > separated numbers). Definitely -- if one is writing the JSON parser from scratch. (Please don't ask me to do that. This is all "spare time" work and that's really just 'busy work'.) > Backends like PHP can choose to ignore the milliseconds when receiving and > not add them when sending. Nope. That breaks my "echo" rule. The server *must* maintain all information it is given such that if it echos back the same date as it receives, no information is lost. The current PHP implementation supports that. > 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). The parsing of the whole string would be easy. It's getting access to that whole string during JSON parsing that's the problem. I spent some time trying to get it to work and didn't succeed. If you feel really, Really, REALLY strongly about it, I'll look again, but I'm pretty seriously disinclined to spend time on that. > 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. I think my statements above make my opinion pretty clear. ;-) > 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. How do we do this in a portable fashion? What if the server doesn't support persistent objects, so you *can't* request a particular instance. I think that instance id is mixing application-specific features with RPC-generic features. > I have no problem with adding a call id, but please leave the original > instanceId functionality in! I would propose to add this feature on top of RPC rather than being part of the generic RPC mechanism, possibly by appending the instance number to the URL. By doing it this way, if the client and server know about instances, they'll be used. If the server doesn't support them, the URL will never include an instance id, and it just won't be used. > 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. Test RPC_4.html shows how one might use async calls and await completion before moving on to something new. I believe this is the safest way to handle the situation. OTOH, I'm not wedded to the warning about sync calls. I believe it should be there to discourage people from using it, but I'm willing to remove it if the team believes it doesn't belong. > A strong warning should be present in the API documention, That I definitely agree with! Then again, who reads documentation? :-) > 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. I made the assumption that, as in my examples, you can use a relative URL (path name only) as I did in the RPC_*.html tests. Yes, I'd definitely like to hear why you need it, but I also have no problem adding the helper method you request. Cheers, Derrell _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
