Derrell,
This is really helpful - I'm not sure why json.org and json-rpc.org are
not working together cooperatively. It seems to me that they should go
hand-in-hand!
(It also appears from the json-rpc.org site that maintenance of this
site is in jeopardy, as the maintainer is looking to pass the task to
someone else. Hopefully, that will be resolved appropriately rather
than just dying on the vine. It is surprising that nobody in the
industry has offered to pick it up.)
Just thinking about this, I'm envisioning the Qooxdoo RPC servers being
able to detect when a Qooxdoo client is making an RPC request and
sending the more efficient date format, falling back to the default
"hinting" method when a client other than Qooxdoo makes a request. (I
remember seeing Hinting mentioned in the json.org documentation, too.)
I think we could generate Qooxdoo RPC calls with a parameter requesting
the Qooxdoo date extension instead of the default standard date
encoding, so that Qooxdoo clients enjoy the benefit of the enhanced
performance from the current encoding while allowing the RPC server to
still respond to non-Qooxdoo clients in a conformant manner.
Anyway, I'm learning a lot this week, and I appreciate the responses
from everyone. Good discussion - thanks to all for participating.
Thanks,
Gene
On Wed, 2009-12-02 at 09:40 -0500, Derrell Lipman wrote:
> On Wed, Dec 2, 2009 at 09:29, Gene Amtower <[email protected]> wrote:
>
> Since JSON date implementations will all end up being
> extensions under the current dailogue, is it possible to
> implement more than one JSON date format as different
> extensions, and allow them to be selected through a property
> of the class, or does this introduce way too much complexity
> in the RPC client and server implementations?
>
>
> It's unlikely that any one server would support multiple date formats
> (there's simply no real reason for it to do so). Each date format
> could be easily defined as a separate extension, with any one server
> indicating support for whichever date format extension it does
> actually support. (This does not preclude a single server from
> supporting more than one format, but it would then also have to
> provide a mechanism for selecting which date format to use... which
> gets a bit nastier.)
>
>
> The other important issue with RPC server inter-operability is
> whether the RPC request and response structures in Qooxdoo and
> other development environments are standardized in any way. I
> suspect each RPC server has it's own way of passing services,
> methods, and parameters that would prevent Qooxdoo from
> calling a .Net RPC server and vice-versa. So, even if we
> change how dates are encoded, a developer would still not be
> able to call any RPC server from any client environment. Am I
> wrong in this regard?
>
>
> Yup. :-) Take a look at http://json-rpc.org and its specification
> link. Other than dates, I believe the only feature that we don't
> support is JSON class hinting, and that "should" be optional (although
> it's not defined that way). We should probably implement that final
> feature (also as an extension) which allow dates to be passed in a
> fully conformant (albeit inefficient from a parsing standpoint)
> fashion. In any case, we could already interoperate with other JSON-
> RPC servers that implement this specification, as long as no dates are
> involved.
>
> 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
------------------------------------------------------------------------------
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
