On Wed, Dec 2, 2009 at 07:57, thron7 <[email protected]> wrote:
>
>
> > current format. No special processing is required at the client side.
> > The current format is eval()'ed and automatically generates Date
> > objects. You
>
> Ah, I see. But then it's not really Json, it's Javascript you're passing
> around, right?! Maybe then the issue could be (better) resolved by just
> renaming the whole thing to "javascript-rpc".
Call it what you will. This is an old argument; just search the email
archives for Andreas J's and my discussions of many years ago. I was trying
to just put some historical perspective into the rationale. There _is_ a
reason to do it the way it's done: for efficiency at the client side. There
are plenty of reasons not to do it the way it's done. That's why I'm
proposing that the current efficient method continue to be supported, but as
an extension.
Or is there a strong argument for aiming for Json?
>
Yes, I think. JSON-RPC is *almost* sufficiently well defined to become a
standard. it would be nice if qooxdoo would interoperate nicely with various
"vendors'" JSON-RPC servers, not only servers specifically designed to
interoperate with qooxdoo. I think that's a goal well worth striving
towards.
Derrell
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
