[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Announce: Prefs distribution thru XML-RPC
There are appropriate uses for an HTTP-tunneled, XML-syntaxed RPC. The example that Userland gave earlier in this thread ("how to save a user's preferences") does not seem like an appropriate use of that technology. For a task as stateless and computation-less as persisting user preferences an "HTTP-tunneled, XML-syntaxed RPC" is overkill and is not yet standardized. A standards-based alternative solution can be realized that uses only static XML 1.0 documents served by a vanilla HTTP/1.1 Web server. Corollary benefits of the approach can also be demonstrated. Winer said in his posting that "the focus is on simplicity". Simplicity is a good thing so let's get out Occam's Razor: "Pluralitas non est ponenda sine neccesitate" or "plurality should not be posited without necessity" or "if two theories explain the facts equally well then the simpler theory is to be preferred" (see http://www.skepdic.com/occam.html). In this message, I will argue that if two solutions satisfy the same requirements then the simpler is to be preferred. The combination of a vanilla HTTP/1.1 Web server and XML 1.0 documents is sufficient for the example and it is simpler than the (rather proprietary) Userland XML-RPC. Although this message seems negative towards Userland XML-RPC, I have to give credit to Winer for sticking through all the outrageous rigmarole that he's been put through with this stuff. But in the end, even if XML-syntaxed RPC makes it easier to explain PRC to folks, I don't think the benefits outweigh the costs. Consider how many people program to DCOM and then consider how many of them actually have ever looked at a DCOM message on the wire. I do not believe that the global network bandwidth and CPU costs are justified. Go HTTP-NG instead. (Seems like memetics could justify this stuff better than any technical argument.) If we must stay within HTTP-tunneled, XML-syntaxed RPC then I think the protocol and the examples need to be better before diving in. ** Terminology: The term "vanilla HTTP/1.1 Web server" is used here to differentiate between the well defined parts of HTTP/1.1 and things like CGI, ASP, or any other 'dynamic' extensions to a basic HTTP/1.1 Web server, including the Userland XML-RPC mechanism. Although the HTTP/1.1 spec, RFC2068, defines HTTP POST, it is but a hook for extensibility. The behavior associated with HTTP PUT and HTTP GET are more fully defined. By staying within the spec, interoperability is increased. Plus the HTTP/1.1 spec work is already done, unlike "HTTP-tunneled, XML-syntaxed RPC". ** The situation: Dave Winer wrote: > Suppose you have a website that is distributed across > several machines, perhaps geographically, with some or all > of them serving dynamic pages with per-user customization. > You want to provide a single place for the user to set > preferences and have the changes percolate to the other > servers on your internal network. First of all, even if the application has 'dynamic' pages. The persisting of user preference does not need to be dynamic (see below). If it is a multi-machine website, I assume that there is a single HTTP server (a reverse proxy) which has the public Internet IP address for the site. That server farms out the HTTP requests to the appropriate worker Web server, that is, the other machines which are part of the site. For a discussion of reverse proxies see: http://www.webtechniques.com/archives/1998/05/engelschall/ Of course if we are just talking RPCing between servers then CORBA or DCOM would work. RPC can already go over the Web via HTTP tunnelling. For example consider Microsoft: http://msdn.microsoft.com/library/sdkdoc/rpc/ov-http_1zw0.htm So, consider using an existing piece of technology which solves the problem better than any current XML-syntaxed RPC mechanism. Plus there are more existing developer tools available for CORBA and DCOM. Perhaps use XML-syntaxed RPC for research but not for deploying applications now. ** The Userland XML-RPC solution: Let me see if I understand what's being described. Dave Winer wrote: > We had to build such a preferences distribution network for > UserLand.Com, and naturally we used XML-RPC to implement it. > > The interface is easy to implement once you have an XML-RPC > layer running. That's a big assumption. What percentage of the currently deployed web servers have this "XML-RPC layer"? If an admin is newly adding this layer to a server then which spec should be choosen: the Userland XML-RPC spec or the one that Userland submitted with Microsoft, called SOAP? There's a very big difference between the two: they don't interoperate, that is, a SOAP talking machine can't discourse with a Userland XML-RPC talking machine (unless there's a newer Userland XML-RPC spec I haven't seen although the last one I looked at was referenced by Winer on Mon, 20 Sep 1999 in: www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0973.html so I don't think that I've missed a new one). Of course, a machine could talk both protocols but that does not seem simple. I find Userland's market positioning of Userland XML-RPC vs. SOAP very confusing. Especially with statements from Userland such as the following: davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem > Two levels of XML-RPC > So there are now two levels of XML-RPC. Here's a pointer to the > specification for the simple protocol: > http://www.xmlrpc.com/spec > And here's a pointer to the new specification: > http://www.xmlrpc.com/soap > It's your choice. Either spec will work. We support both. Let's > have fun! >From "Two levels" I infer interoperability as if Userland XML-RPC were a proper subset of SOAP. Perhaps I'm simply confused by their terminology; maybe "XML-RPC" and "Userland XML-RPC" are different things in their vocabulary. If so, then someone needs to talk to the marketing department. At the very least they seem to be saying they have an offering which works with both XML-RPC and SOAP. I'm confused. Of course, he goes on to say: > Finally, every big company will probably launch their own > specification. Implementors should be aware of this, and should > plan their software interfaces accordingly. Expect wiring-level > incompatibility and you won't be surprised. Not surprised but still not working. Back to Winer's message: > It consists of a single RPC handler, > updateMemberInfo, on each of the affiliate machines. So each machine needs to deploy an "HTTP-tunneled, XML-syntaxed RPC" mechanism. A less onerous lowest common denominator would be nice (see below). > It's a little more complicated on the preferences hub -- it has to > implement a database of affiliated machines, and call each > machine when a preference is updated. So this solution needs a database (and some DBMS?) and a notification mechanism(?). > On either side, it's a very easy implementation and it > delivers a feature that users want. OK, but I don't think there are any users saying "I want my preferences managed via Userland XML-RPC." So, there's a requirement but no constraint on the implementation. > Like all the next-level-up specs we're doing for XML-RPC the > focus is on simplicity, and should work equally well with > SOAP or other transport-level protocols. Winer references the following URL: http://www.xmlrpc.com/stories/storyReader$496 There we find an example methodCall for persisting preferences: <methodCall> <methodName>updateMemberInfo</methodName> <params> <param> <value>default</value> </param> <param> <value>bull@m...</value> </param> <param> <value> <struct> <member> <name>appearance.alink</name> <value>pink</value> </member> <member> <name>appearance.bgcolor</name> <value>beige</value> </member> <member> <name>appearance.link</name> <value>navy</value> </member> <member> <name>appearance.text</name> <value>black</value> </member> <member> <name>appearance.vlink</name> <value>teal</value> </member> </struct> </value> </param> </params> </methodCall> The above says that bull@m... wishes to persist his preferences for the following: appearance.alink appearance.bgcolor appearance.link appearance.text appearance.vlink And for some reason that I do not understand the (supposedly) universally unique email string "bull@m..." is insufficient to resolve to the correct user's persistent store so Userland needs a group name (in this case "default") to help. Perhaps this is an artifact of the black box where in all this info really ends up getting stored. Or maybe there's some legacy directory service stuff going on. Speaking of black boxes, what happens if Userland folds? One of the reasons that SQL became so popular was that it is easy to migrate from vendor to vendor. If it comes time to migrate, it would appear to be simpler to apply some transforms to an HTTP collection of XML documents than extract the data from Userland's system (or any other early "HTTP-tunneled, XML-syntaxed RPC" system). For example, how do you enumerate over the preferences of all the users in Userland's system? With HTTP/1.1 you would just do a GET on the collection and then a GET on each document in the collection (and then transform each document). Finally, in this "persist user preferences" example I don't see any "state" being maintained in software objects (e.g. of state: "please add the following numbers together, then add them to the historic running total resulting from my previous RPC calls and return to me the sum and don't forget to remember my running total for the next time I call you."). If an application needs to maintain state between method calls then there is an argument for RPC. I could even see a reason for a stateless object which does some computation (e.g. "please add the following numbers together and give me the sum" i.e. no state maintenance such as a "historic running total") but a pure persistence problem does not require even this. ** An HTTP/1.1 and XML 1.0 solution: An alternative solution would seem possible using simply a vanilla HTTP/1.1 Web server and XML 1.0 documents. We could just cook up something like: <userPreferences> <pref id="appearance.alink">pink</pref> <pref id="appearance.bgcolor">beige</pref> <pref id="appearance.link">navy</pref> <pref id="appearance.text">black</pref> <pref id="appearance.vlink">teal</pref> </userPreferences> Then we could simply HTTP PUT the doc to a Web server at an URL, say, example.com/userprefs/bull%40mancuso.com ('@' is reserved in URIs so "%40" instead). This solution requires nothing more than vanilla Apache (or any generic HTTP/1.1 server). Further, with this solution an end-user could control where the preferences are to be stored. They could be parked on any HTTP/1.1 server where the end-user has PUT permissions. Perhaps the end-user likes privacy. In that case the preferences could be stored in a HTTPd in the localhost, that is, the info would never leave the client machine. Consider what happens if this user preferences persisting mechanism is to be shared with other sites? The two sites could simply agree on areas of their Web servers where some XML docs can be PUT to the servers. To do that in the Userland XML-RPC way requires...(see above). With this solution I could also benefit from HTTP caching and If-Modified-Since for a simpler, cheaper, and more scalable solution. ** Conclusion It seems that in Userland's offering XML-RPC is being used as a complicated replacement for HTTP PUT and HTTP GET. I know this is no surprise to the folks on this list, but there will always be some 'static' document publishing nature to the Web. So things like HTTP GET and HTTP PUT aren't going away any time soon. So use Occam's razor and use what you've already got: HTTP/1.1 and XML 1.0. No need to posit a plurality. I'm just guessing at Userland's situation but if it's anything like the above picture, I would think hard before deploying the solution. Perhaps I am missing something. Time to get off the SOAP-box, /John -- John Tigue john.tigue@t... http://www.tigue.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|