Hi Danny and Derrell, Am 22.06.2006 um 04:54 schrieb [EMAIL PROTECTED]:
> "Danny Adair" <[EMAIL PROTECTED]> writes: > >> 1. What about simple dates of the form "new Date(Date.UTC >> (2006,6,20))". It >> seems cumbersome to specify zeros all the way down to the >> milliseconds when >> you don't care about time. As usual, 0 would be assumed if >> omitted. So the >> format could look more like: >> "new Date(Date.UTC >> (year,month,day[,hour[,minute[,seconds[,milliseconds]]]]))" > > Incomplete dates will never be sent by qooxdoo; it always retrieves > and sends > all fields. Since we don't know how the protocol is being used > (i.e. who the > two peers are), I think it's best to just always include the > complete date. > That way, there's no uncertainty of how to parse it. You are > correct that it > is sometimes superfluous, but let's include it anyway. I'll adapt the Java implementation to handle numbers that are left out (currently, only the milliseconds are treated as optional). Looking at the JavaScript reference, only year and month are mandatory. Should we handle it the same way (i.e. should we state that an implementation SHOULD be able to only work with year and month)? >> 2. You mention "6 is June" when going through the tokens, but in your >> example date you use "06" for the month. Maybe clarify on >> optionally leading >> zeros. > > I'll clarify that. Thanks. Actually, the month is counted from 0 in JavaScript (don't know where they'd get that idea from ...). You can also see it in the JSON debug output when sending the current date. I've changed the server writer's guide accordingly (oh, and thanks a lot for the guide, Derrell!). On the subject of leading zeros: they should be disallowed in the protocol. In JavaScript, a leading zero indicates an octal number, so things like 08 are technically illegal (and 0777 means 511). Both IE and Firefox can work with 08 anyway (by not interpreting it as octal if there are illegal digits like 8). However, Firefox emits a warning in this case, and I think we should avoid that (and I'm not sure how other browsers handle this). >> 3. Your extension of "service" to the request seems superfluous. >> It seems to >> assume that there is only one entry point. >> Isn't the server URL already specifying the service? >> http://myserver/sevices/myservice >> http://myserver/services/myotherservice >> The method name could then be dot.delimited if there's an object >> hierarchy >> on the server. > > You are correct that it could be part of the method name. I > believe what will > generally occur in usage, however, is that the service name will > remain > constant (or will change rarely) for a particular application and > can be set > once (or a very few times), and various methods within the service > will be > requested frequently. Having the service split out is really for > efficiency > of the client. I agree. > OTOH, having a separate field for the service is a (possibly > unnecessary) > extension to JSON-RPC. What do others think? Should the service > just be > combined with the method? It's there primarily because the java > implementation had it. Andreas J., what do you think of dropping > the separate > service name? Please don't drop it! At least in Java, it would make things quite a bit more complicated. However, you can simply omit the serviceName parameter on the client side (and ignore the serviceName property when looking at the response on the server). It doesn't do any harm to people not using it :-) Regards, Andreas -- 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 All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
