Archive of UserLand's first discussion group, started October 5, 1998.
XML-RPC Spec Comments
Author: Simeon Simeonov Posted: 1/29/1999; 8:11:02 AM Topic: XML-RPC Spec Comments Msg #: 2563 Prev/Next: 2562 / 2564
Dave,As per your request I am starting this new thread on the the XML-RPC spec. Here is how I think it should be done:
- Split the spec so that it talks about four separate layers: transport, request/response encoding, data encoding, and server. The general specification of each of the layers should mostly talk in logical terms pertaining to the information the layer needs/produces and the transformations it performs. For example, you can say that the transport layer should implement request/response semantics and be able to transport the XML packet describing XML-RPC requests/responses.
- Document at least two types of transports: HTTP(S) with content type text/xml (what you have now), and HTTP(S) with content type text/html (and all its varieties) which is useful for generic web applications that might want to expose XML-RPC functionality. I had suggested using hidden formfield variables with well-defined names for this. It might be nice to allow URL parameters to be used instead of form fields, although then large requests will fall prey to URL size limitations. The benefit is obvious: a link can encapsulate a request.
- Require that in addition to object, method, and arguments information the request also includes information about which version of the encoding is being used. This will save you a lot of hassle in the future and will allow a server to handle legacy requests. The response should use the same version as the request. It may not hurt to specify the version there as well, though.
- Document the existing encoding for XML-RPC extending it with optional version information defaulting to whatever the current version is.
When the XML-RPC spec gets to this point of modularity we can meaningfully start talking about WDDX integration, etc.
The one problem that I'm still grappling with has to do with a single server accepting requests with multiple encoding types (as opposed to versions of the same encoding type). There are four ways to handle this:
- Let the server determine this by looking at the request packet. This can involve some ad hoc coding but it allows plug'n'play use of "modules" that might produce a request in a specific encoding. That's very appealing.
- Specify a mandatory top-level element for all encodings that specifies the name of the encoding used. This doesn't allow for plug'n'play and it makes integrating decoders into the request parsing tricky. This worries me.
- Postulate that a server may have multiple entry points, e.g., URLs, but that each entry point can only understand one encoding. Here the entry point automagically determines the decoding strategy. This is appealing, but leaves it to the requester to know whom to call. This doesn't seem too bad, though, as the requester probably knows what encoding it's going to use.
- Specify that the encoding type must be communicated via the transport. Essentially, we are adding an extra encoding type demultiplexer layer. For example, the transport using content type text/xml can automatically infer that it is using the traditional XML-RPC spec. The transport using content type text/html can pass a separate hidden form-field variable or URL parameter. In this scenario we have a way to pass structured information about the encoding type without mucking around with the encoding layer. Defaults can ensure that backward compatibility is fully maintained. This is my favorite.
What do you think?
Regards,
Sim, Allaire
There are responses to this message:
- Encodings; was Re: XML-RPC Spec Comments, Bob Atkinson, 1/29/1999; 1:42:43 PM
- Re: XML-RPC Spec Comments, Dave Winer, 1/30/1999; 7:45:58 AM
This page was archived on 6/13/2001; 4:47:39 PM.
© Copyright 1998-2001 UserLand Software, Inc.