xml-dev - Re: Announce: Prefs distribution thru XML-RPC

["Dave Winer" <dave@userland.com>]

John, I can save you some trouble -- you don't have to tie into this
network. Our customers want it. We also promised that we wouldn't lock them
in to UserLand-only solutions. So as long as we're providing an open
interface, which we are, we have to announce what we're doing, why not tell
the XML-DEV list about it. I don't expect the world to galvanize around our
solution unless it's the right thing to do.

As to why we continue with XML-RPC even though SOAP is out, it's pragmatic.
We have a lot of stuff we do with XML-RPC. Our SOAP interfaces aren't even
slightly deployed yet. That's a kind way of saying that at this time our
*only8 choice is XML-RPC. You're right, the vast majority of messages are
unexamined. It could be that this time next year all our messages will be
SOAP-encoded. That would be fine with me. I'm interested in the next-level
up, and am keeping the options open in case more developers prefer the
simpler format. The jury is still out on that.

About whether or not static XML files would do, of course you could do a
polling thing, but this is a lot simpler to implement, again, assuming you
have an XML-RPC layer. If you don't no problem, do the static file thing.
Have fun. Be a pioneer.

This is a lot less heavy than you think. Let's have fun. If this doesn't
become a standard there will still be a Christmas and the birds will still
sing.

***More philosophy

Since you're quoting from DaveNet, let me do the same. From "Sell What You
Have" :

http://davenet.userland.com/1997/01/05/SellWhatYouHave

I remember a conversation with Jean-Louis Gassee in 1989, when he was head
of Apple's product development. We were talking about the scripting software
I was developing, which eventually became Frontier.

We also talked about HyperCard, which was then the most powerful scripting
software for the Macintosh. I said (of course) that our software would be
much more sophisticated than HyperCard, more for geeks, but simpler, deeper,
faster, more useful. Jean-Louis encouraged me to tell him more. I did. I
like talking to JLG because he likes geek talk.

So then he asked me a question that I still think about. He asked, "Would it
be all right with you, if in the meantime, we continued to sell HyperCard?"
I laughed! I'm laughing now. It's a funny question!

"Yes, of course," I said; secretly wishing that he would immediately lose
interest in HyperCard, and commit fully to my new system scripting design.
I'm just a human being, looking for the easier path, for me, of course.

His question is still teaching me lessons, and looking at the history of
Apple, which is anything but Sell What You Have, it seems, based on reading
tea leaves, that we are probably going to get a chance to learn more about
this next week.

***Anyway

That's my philosophy. I'm selling what I have. You don't want to buy. OK.
But you never know how it's going to turn out. I've seen platform vendors
trip up, even Microsoft. Sometimes the low-tech solution wins. Actually if
you look at the way the Internet works, you might conclude that the low-tech
solution *always* wins.

One more thing, it's totally not fair to call this UserLand XML-RPC. Look at
the home page of the site, there are independent implementations done for
lots of different languages and environments, and none of these were done by
UserLand. And the initial design was done by Developmentor, Microsoft and
UserLand. You're too smart John to do that accidentally, so please be more
careful.

Dave




----- Original Message -----
From: John Tigue <john.tigue@tigue.com>
To: xml-dev <xml-dev@ic.ac.uk>
Sent: Tuesday, September 21, 1999 3:33 PM
Subject: 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@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@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@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@tigue.com
> http://www.tigue.com
>
>
>
>
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)