Announce: Prefs distribution thru XML-RPC
John Tigue
john.tigue at tigue.com
Tue Sep 21 23:30:23 BST 1999
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 at mancuso.com</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 at mancuso.com 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 at mancuso.com" 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 at tigue.com
http://www.tigue.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list