Hi everyone,
Fabian Jakobs wrote: > > Yesterday I've landed a commit, which adds native JSON support to > qooxdoo. [...] This is great news because parsing > and serializing JSON is a lot faster on those browsers. > Cool! :-) Fabian Jakobs wrote: > > BUT > we cannot deprecate the old implementation yet. > I knew that this was too good to be true... :-D (Just kidding, I was already aware of this limitation.) Fabian Jakobs wrote: > > Since the RPC code is the only code depending on this feature I would > like to know from the RPC authors: > > 1. Wouldn't dates represented as ISO strings be sufficient? Do you think > we need a special date extension? > I'm not sure if we need a special date extension. In our (custom) RPC implementation, we don't use this extension but do pass on dates back and forward... (I already stated something related in the bug tracker [1] but here goes:) We have high accuracy requirements for dates, so we use a two integer array: first meaning seconds since 01/01/1970 and the second meaning the fraction within the second. As usual, this has positive and negative aspects: (+) It's damn fast to turn such an array into a JavaScript Date object; (-) It's (very) hard to read to humans; (-) There is no class hinting stating to the parser that this is actually a date. The client/server needs to know implicitly where are these special arrays located within the received data; (-) This will explode in 2038, where the first integer will overflow. Although JavaScript implementations are required to use 64-bit, tests I've done a few years ago have revealed that this isn't fulfilled for most. Of course this gives us a lot of time to workaround a solution, but it seemed fine to share as we're at it. :-) In the same bug report it's suggested that data binding features of qooxdoo would be used to cover this caveat, which I though to be an elegant solution! ;-) Fabian Jakobs wrote: > > 2. If we find a standard compliant way to serialize dates, would you > update your backend code? > Yes. Sniffing strings for ISO dates would also sound good, but I'm afraid it will mean an important overhead when there are large/complex objects flying over back and forward... :-| Fabian Jakobs wrote: > > 3. Do you think everything is fine and we should just keep both JSON > implementations? > Keeping both implementations means more code to maintain and probably, in the long run, more bugs to fight with... :-( Fabian Jakobs wrote: > > I'm really interested in your feedback, > > Best Fabian > Cheers, Helder [1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1400#c14 -- View this message in context: http://old.nabble.com/RPC%3A-We-need-a-standard-compliant-way-to-serialize-dates-tp27210452p27214978.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
