Hello Christina, > I am currently porting Martin's json-rpc/node code [1] to qxoo to run on the > server (as a contribution named "RpcNode"). Thats really good to hear that my code is worth something at last. :)
> In contrast to Derrell's RPC implementation [2], the current 1.0 [3] and > 2.0 [4] specifications have no "service" parameter, but only a "method" > name. I consider this a deficiency, and so do people on the json-rpc list > [5]. There is a pending feature request to introduce an optional "service" > parameter in json-rpc version 2.1. Thus, I think it would be unwise to > remove the "service" parameter from the json-rpc implementation and break > compatibility with the existing qooxdoo json-rpc server, just to have to > re-introduce it later. I am happy to provide arguments why I think the > current spec is deficient in this regard. > > I will thus implement an optional "service" parameter, which will will work > the following way: If provided, the server will try to require() a class > with the name of the service, which will have to subclass rpcnode.Service", > if it hasn't been loaded already. If the parameter is not given, the default > service class will be used. I think its important to keep exact to the spec, well at least make it possible to use it as the spec suggests. I have filed a bug today to reimplement the RPC layer to fulfill the spec at all. I haven't took a detailed look at the current implementation but my goal is to provide a good implementation for JSON RPC spec 1 and 2. So the service parameter can only be optional in the new layer which would fit your implementation as well. Best, Martin ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
