[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2002-02-11 at 15:40, Paul Prescod wrote:
> Until you make a technical argument you're just making assertions. "XML
> was wise to reuse the angle bracket infrastructure that had worked for
> HTML, but that doesn't make XML a brilliant fundamental architecture." I
> can play that trick on any technology.
Definitely. But XML builds on a solid foundation - locally-labeled
nested hierarchical structures. HTTP builds on a pile of headers with
limited hierarchies and ad hoc structure.
> That's fine. If you don't care about scale then your options become much
> broader and REST doesn't have much to offer. I typically encourage
> people with simpler problems to use XML-RPC.
Except that XML-RPC also uses HTTP, is really (brilliantly but still)
limited in its capabilities, and doesn't actually let you use XML for
messages at all. I think your typical suggestion is the wrong
suggestion for the kinds of objections I've raised.
> > Why on earth would I build "the One True Caching Proxy for all
> > customers"? Have I been watching Highlander too many times?
>
> No, you need one caching proxy because all of the information on your
> network comes through a very few interconnects with other systems and by
> compressing the information at that one point you can save yourself
> hundreds of millions of dollars and pass those savings on to either your
> customers or your shareholders. Plus, you can deliver data to your
> end-users more quickly.
And if you put millions of users behind a single firewall you deserve
the problems you get that way. I guess you haven't read the
long-running battles on NAT considered harmful at the IETF, which
address a lot of these issues.
> "There can
> > be only one." Am I completely hung up on centralizing everything and
> > running it through the same blender? Have I forgotten about the
> > prospect of distributing systems and permitting local control over
> > processing logic?
>
> Local control is fine. Aggregating caches exist precisely to allow
> end-users to get more efficient access to their data and drive network
> costs down. Nobody loses control. Everybody benefits.
Everybody benefits, provided they're happy about the contract which
permits them to use that system. I'm not happy with the contract for
reasons you seem to find impermissible.
> You're right. I don't want to be in the point-to-point bridge building
> business. I'm happy to admit that that isn't where HTTP excels. XML-RPC
> is wonderful for that.
I really hope you're using "XML-RPC" generically and not to refer to the
protocol described at:
http://www.xmlrpc.com/spec
XML-RPC (at that URL) strikes me as the furthest an HTTP-based system
should go into messaging, but it's an extremely limited set of
capabilities.
Even if you are using it generically, I don't find RPC very consistent
with the message style I'm proposing - in fact, I find REST to have too
much RPC in it. All those verbs are just kind of procedure calls in
their own way.
> This is more or less the model used by functional programming languages
> that have nothing *except* recursion. It is known in that world as a
> "continuation." It's also a proven strategy on the Web as we use it
> already.
Labels are handy. Labels are not state.
> > Sure. Inclusion by reference to the current state of the conversation
> > is normal. Humans do it all the time. That doesn't mean I want to
> > send a pile of URIs every time we converse, though.
>
> You don't need to send a pile of URIs. You send one. It refers to the
> last state of our transaction. Then you add some information. That "last
> state" can contain URIs to all previous ones, or embed them.
And somewhere, there's a pile of URIs describing state changes - or
we've chucked them all.
> > Sure. And if someone else comes along and changes the state out from
> > under your label, how much good is your label?
>
> That's why you make some URIs static rather than dynamic. If you use
> Expedia, you do this all of the time. You can go through several steps
> of a transaction and get a URI. Then you email that URI to your wife and
> let her go a couple of steps further. Then she emails it back to you and
> you finish it. Only your wife and you have the URI. Only you have the
> password. Nobody else can overwrite or otherwise interfere with your
> transaction.
Sorry Paul, you're in a different place. That such interruptions work in
a Web browser is not sufficient cause for me to reproduce that model
throughout my network applications.
> Sure, that's the SOAP envelope model. Move the headers down into the
> document. If you don't care about working with today's Web then that's
> fine. You'll end up reinventing a ton of stuff but I guess that's kind
> of fun.
No, it's not much fun. I said at the end of my previous message that
the SOAP envelope is just another crap header. Same mess as HTTP,
different location. Neither impressive nor particularly useful.
> > I guess you've never been through the pain of writing an entire book on
> > Cookies. HTTP may be good enough for a lot of things, but calling it
> > wonderful is a hard sell.
>
> Cookies are not part of HTTP. They are actually a pretty poor idea. And
> of course they are irrelevant to web services and distribute computing.
Cookies are a symptom of what the HTTP header approach makes possible,
at the very least. Cookies actually get lots of use in Web Services and
distributed computing. Last I looked Apache SOAP was using them, not to
mention most of the services that work like the Expedia example you
provide above.
REST is just a subset of RPC, I'm afraid, calling arguments headers
instead of parameters and privileging the message-body parameter. At
least it's less RPC than some of the other options.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
