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
>
I think all sides have made good arguments, but in the end it boils down to
Derrell's original suggestion - move the current Date formatting into an
extension. Whatever new formatting anyone else wants to see implemented - it
is all possible, just write an extension for whatever server you want, and
give it a name and a specification, and then the server can inform on the
availability of this extension when it is queried with
system.getCapabilities(). All you need to do is to provide good
implementation documentation and willing implementors.
BTW there is already a new json-rpc 2.0 specification:
http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
with interesting new features. It also provides for "extensions" - however,
has no grammar for querying them.
Cheers,
C.
--
View this message in context:
http://n2.nabble.com/Rpc-backend-harmonization-tp4075821p4100752.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
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
