[
Lists Home |
Date Index |
Thread Index
]
Gavin Thomas Nicol wrote:
>
>...
>
> This is probably true. I also think that a lot of people claiming
> great things for HTTP are claiming more than it was intended for...
HTTP is the protocol designed to support the Web. According to Tim B-L,
the "Web's major goal was to be a shared information space through which
people and machines could communicate." How much more scope could we
attribute to HTTP than that?
But really, I don't see the point of the Web anthropology. The Web
exists. It is incredibly successful. There is no doubt that Stone Soup
effect is a big part of that. I also claim that a couple of key design
decisions were central. One is to have a single, unified address space
for all information.
If that's the case, what are the implications for web services? What
does SOAP have to say about a single, unified address space for all
information?
> and fail to see that HTTP+a set of application/URI-space semantics
> isn't the same as HTTP itself.
That's another semantic game of little relevance. Can XML be used to
encode any data structure? Is a purchase order a data structure? Can I
define an XML vocabulary for purchase orders? If I do so, am I applying
a layer of semantics on top of XML? Am I still using XML?
Can XML be used for purchase orders? Yes.
Can HTTP be used for peer-to-peer communications? Or asynch
communications? Or reliable communications? Yes. In exactly the same
sense.
Is it a good idea for XML to be used purchase orders? That's an
engineering question. It takes thought, effort and discussion to decide.
Is it a good idea to use HTTP for peer-to-peer or asynch communication?
Ditto. It doesn't do to merely wave the hands and claim that HTTP wasn't
designed for these things. HTTP was designed to be a general purpose
data sharing protocol, as XML was designed to be a general purpose data
structuring protocol.
>...
> I find an ironic example of when I've been guilty of something
> similar. Many moons ago, I tried to get rid of the URL-encoding
> bogosity on GET submissions from forms, because from an I18N
> perspective (and for other reasons), it is abhorrent at best. HTTP did
> (and last time I looked still did, though I'm fuzzy on HTTP 1.1 now)
> support an entity body. My thought was to use that instead... as you
> could make it I18N safe etc.
>
> I was told, in no uncertain terms that "HTTP doesn't do that",
> "servers don't do that", "even though it's allowed, it's not correct
> usage", etc. I think saying that HTTP can do broadcast is roughly akin
> to this.
I don't see the analogy at all. If I understand the suggestion then I
would object to it not on the basis of any detail of the implementation
of HTTP but on the fact that it violates web architecture as I
understand it. GET takes a URI because HTTP is address-centric. If you
move the data into the entity body instead of the URI then you are
moving to an FTP model. Plus, you might as well use POST.
> > How is it mediocre? Now that I'm coming to understand it, I think
> > it's brilliant.
>
> Don't confuse the original HTTP with what you see you can do with it.
What is the relevance of this "original HTTP"? HTTP was re-designed from
the ground up. I'm talking about HTTP of today.
Paul Prescod
|
