Archive of UserLand's first discussion group, started October 5, 1998.

Re: WDDX Annotated DTD

Author:Simeon Simeonov
Posted:1/13/1999; 12:49:22 PM
Topic:WDDX Annotated DTD
Msg #:2103 (In response to 2089)
Prev/Next:2102 / 2104

How about: 


   examples.getStateName   
   ...

or, perhaps, 



   

   
      
         
             MyObj.MyMethod
         
         
            ...

I'm partial to the second version of the syntax. Let me explain why.

The making of an RPC call involves making decisions about a number of things:

- The information you want to provide, e.g., protocol version, object name, method name, arguments.

- The way you will marshal (encode) this information for transport.

- The way in which the information will be transported.

XML-RPC gains simplicity by not separating these issues but it does loose some flexibility. For example, why postulate that "An XML-RPC message is an HTTP-POST request"? Why not allow an XML-RPC request to be received other a named pipe or a socket? (I'm thinking about the benefits of XML-RPC outside the immediate context of the Web here...)

If one takes the view of focusing on the important _information_ about an XML-RPC request one ends up with two pieces of data: a method name and an array of arguments for the method. How they are encoded is sort-of incidental. In fact one would want to choose an encoding that is about as plug'n'play as possible.

My first proposal above combines some of the existing elements of XML-RPC with a WDDX packet containing the method arguments. The problem with this approach is that one would have to change existing XML-RPC implementations to work with a WDDX serialization/deserialization module.

The second proposal is simpler in my opinion because it allows an XML-RPC implementation to determine by looking at the beginning of the packet whether the _information_ about the RPC call is encoded using WDDX or using the traditional XML-RPC syntax. In the former case it can leverage an out-of-the-box WDDX "module" (available for ColdFusion, COM [Active Server Pages, VB(script), JS, C/C , Delphi], Perl, Python, PHP, and hopefully soon--Frontier) to get the data from within the request and then pass it on to the piece of code that actually satisfies the request.

To me, looking at the beginning of the packet and choosing a "decoder" based on this is a lot simpler than extending existing implementations to plug in WDDX processing at some point.

Also, it will essentially allow s.o. to send and receive XML-RPC requests and responses w/o actually having an XML-RPC implementation on the client, just knowing WDDX. That takes one layer of custom software off! I think this is a good thing.

Let me reiterate: I think the core value of XML-RPC lies in the model of request-response processing it provides and in the server implementations that execute the requests. The actual encoding of the request and response data and the transport protocols are of practically no importance except for the fact that they should be simple, widely available, and flexible.

I'll be interested in hearing your comments!

Sim Allaire

There are responses to this message:

This page was archived on 6/13/2001; 4:47:16 PM.

© Copyright 1998-2001 UserLand Software, Inc.