On Mon, Jan 18, 2010 at 07:32, Fabian Jakobs <fabian.jak...@1und1.de> 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?
> 2. If we find a standard compliant way to serialize dates, would you
> update your backend code?
> 3. Do you think everything is fine and we should just keep both JSON
> implementations?
>
> I'm really interested in your feedback,
>
Andreas J. and I had long conversations about this extension many years ago,
as part of a standardization of qooxdoo JSON-RPC implementations (Java and
PHP, at the time). Since then, there has been ongoing discussion about the
optimizations that could be made by eliminating the extension. The PHP
JSON-RPC server has, in fact, a flag to disable the extension and use the
native JSON formatters/parsers. That requires a cooperative agreement
between the server and all of its clients that the clients will not try to
use the qooxdoo date format (i.e. they will not format Date objects). I
don't believe that there are currently any properties in the client code to
specify whether special Date processing is required.
In more recent discussions, we've talked about the concept of JSON-RPC
server extensions. I've recommended that the Date processing be implemented
as an extension, and the client be able to determine whether the server
supports that extension. I continue to support this recommendation.
Applications have long been provided with Date processing capability, and
it's a worthwhile capability. With the addition of a property in the RPC
class, we could easily switch between the efficient, built-in JSON
formatters/parsers, and the less-efficient, but extensible, JavaScript ones
currently being used.
In answer to your specific questions:
1. Dates represented as ISO strings must be converted by the application,
thus it's much less desirable than having Date objects once parsing is
complete.
2. Sure, I'd be glad to support standard-compliant date serialization.
AFAIK, though, there isn't any.
3. I don't think everything is fine, but I do think that at least until we
come up with a better solution, what I proposed above, with a property to
select the internal or external fromater/parser and a queriable extension at
the server solves the problem.
Derrell
------------------------------------------------------------------------------
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
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
