Team,
Trying to be more conformant with the date-encoding used by other RPC
implementations was the purpose behind my question, and I appreciate the
dialogue on the topic.
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? The default
might be an industry-conformant encoding method that requires parsing
and conversion, while the existing format that can be eval'd becomes an
additional optional extension? Or, the current Qooxdoo method could be
the preferred extension. It doesn't matter either way to me, but having
a choice as a developer could be useful, except for the following...
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? If not, then this discussion about date encoding doesn't really
affect the ability to inter-operate. In that case, the Qooxdoo client
would need to be smart enough to know how each RPC server needs to
receive the request and how it's going to format the response - there
could be a lot more complexity in the code and still not always work as
intended. SOAP defines request and response structures, but I don't
remember seeing anything relative to them in the JSON definition.
So, maybe this goal isn't realistic, which means the date encoding isn't
really an issue either. Our backend harmonization discussion may just
need to focus on the Qooxdoo-based backends, without considering
external environments. Am I missing some vital understanding in this
area?
Thanks,
Gene
On Wed, 2009-12-02 at 08:53 -0500, Derrell Lipman wrote:
> 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
------------------------------------------------------------------------------
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
