Andreas Junghans <[EMAIL PROTECTED]> writes: >> Which specification are you following for the implementation in RPC.js and >> RpcServlet.java? > > It doesn't follow a published specification. We (Til and I) needed an easy > JavaScript-Java-RPC, and JSON looked like a good, simple serialization > format. JSON-RPC seemed like a natural choice for the RPC protocol, but it > has some shortcomings:
Agreed. I understand what you did, and why. > - Using an ID for each asynchronous call doesn't seem very elegant. Using > seperate handlers for separate calls seems more logical. Using separate handlers for separate calls is fine, if the calls are to different procedures. If you're issuing a whole bunch of calls to the same procedure, most likely you'll want the same handler, so the ID matches a particular response to a specific request. This is actually a very standard process, used in most networking protocols. The ID is optional here, so you can use just the handler as the response identifier if desired, but having the ID also available is, IMO, a good idea. > To my knowledge, neither Google nor Yahoo uses JSON-RPC as layed out in the > JSON-RPC spec (but they're using JSON as a serialization format) - please > correct me if I'm wrong. If that's true, then we have less to worry about as far as compatibility. I'll look into it some more. > Changing the names of fields (or putting exception names and messages in a > separate error object) is no problem. Patches are welcome as long as the > functionality stays intact. Thanks. Assuming that there is not widespread use of some JSON-RPC protocol by the big guys (e.g. Google), what I'd like to do is make our implementation match, as closely as is reasonable, the JSON-RPC spec. For those things that can't (or shouldn't, due to technical issues, such as Date), we can put together a proposal to the JSON-RPC folks to update the spec with the issues we identify. I'd also like to identify a set of "common" error codes which are likely to arise in nearly any implementation (service not found; method not found; etc.) and add those to the spec if possible. Cheers, Derrell ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
