"Danny Adair" <[EMAIL PROTECTED]> writes: > But why handle it differently on the server side? > Why a _data_ field, why not just a (service,) method, params and id field?
When a message is being sent, the choice of which transport to use is done way down in the bowels of the RemoteRequest process. The message to be sent (the JSON-serialized RPC request) has already been generated; it's a textual representation of a single object. There's no easy way, at that point, to split it into its constituent parts. Also, I think we want to keep it as a single object. The server may want to pass it off for processing, and the whole request should be encapsulated until the server is ready to parse it. > Some server implementations already delegate requests to different handlers > depending on their content-type, and that might be slightly different. Same > with the clients. > In qooxdoo, maybe make it an optional parameter with those as defaults. qooxdoo doesn't call the JSON-RPC handler if the content type is not one that tells it that the the content must be so handled. qooxdoo has to be able to receive both JSON-RPC replies and straight javascript, and it handles them differently. There could be multiple content types that serve that purpose, but I'm not convinced that there's a compelling reason to add complexity in this case. > And now I understand why you have the service parameter. :-) Good. :-) Cheers, Derrell Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
