[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
>
> Sorry. I disagree. The protocol layers are not intrinsically capped. You are
> just imposing the perspective of one protocol layer and declaring it as
> absolute. HTTP is not the center of the computing universe. I could just as
> well argue that TCP is the top level protocol and HTTP is just tunnelling.
As far as I know, HTTP respects *all* of the semantics of the TCP
protocol. In fact, the binding between HTTP and TCP is very clean and
natural. But HTTP is not an extension of TCP because it depends on a
minimal number of services from TCP -- just a streaming, bidirectional
connection.
> Indeed, terms evolve and change their definition over time. Thinking that
> you can freeze vocabularies and cast them in stone forever is terribly
> naive.
The terms are extremely expressive as they are. You want to make them
muddy by using an application protocol as a transport protocol. I think
that the burden is upon you to argue why that change in terminology and
model is virtuous.
> ... Web services have opened up the possibilities of layering new
> protocols upon HTTP in rich ways -- and in ways such that these higher level
> protocols are not dependent upon whether they are operating over HTTP, or
> SMTP, or some other transport (and from the perspective of these layers,
> HTTP is transport, not the application layer).
This is the faith. A protocol is a definition of how to move bits
around. Does it actually make sense to define a protocol that doesn't
care about how the bits are *actually* being moved around, whether they
are being moved around reliably or unreliably, synchronously or
asynchronously.
> ... The protocols are based on
> the correlation of message structures between requests and responses. So
> where is the metaphysical law that declares that such a formulation cannot
> be considered a protocol?
Sure, you can tunnel a protocol on top of a protocol. Nobody said
otherwise! You could run IP over SOAP...or over pigeons for that matter.
You haven't yet made a case that infinite the tower of protocols buys
you any power. I'm asking for a technical argument instead of an
assertion. It would be easy to prove me wrong. Describe a web service
that requires a nine-layer stack and cannot be implemented through HTTP
and semantically-compatible extensions.
> ... The view you put forth is very narrow and biased,
> and it simply denies innovation and the evolution of technologies. I would
> argue that your definition of "protocol" is just too narrow to be useful to
> web services.
You've asserted that. Please demonstrate it.
> > That is not true. SOAP authentication will be an extension of
> > SOAP.
>
> Oh really? So when I send a PDF document over HTTP, does that mean PDF is
> just an extension of HTTP?
No, because the PDF document will have no knowledge that it is being
embedded in HTTP. It has no integration with HTTP semantics. Similarly,
HTTP does not really know about TCP other than that it is a
stream-oriented, connection-based reliable data protocol. On the other
hand, SOAP authentication is called SOAP authentication because it is
explicitly designed to integrate into, and build upon, the SOAP model.
It isn't called "protocol authentication" because it is explicitly tied
to SOAP. It is an extension of SOAP.
But in fact, SOAP authentication is neither a protocol nor (AFAIK) does
it claim to be one.
> ... Some of the arguments that get advanced, here,
> really baffle me. Just look at SAML[1], or DSML[2]. These provide SOAP
> bindings of their structures, but also allow bindings to other "protocols"
> (and, yes, dammit! I am using the word "protocol", here). How would you
> argue, then, that SAML or DSML are just SOAP extensions?
(AFAIK) SAML and DSML do not claim to be protocols[1]. That's why they
end in "ML", not "P". They do not define standards for the transmission
of data across networks. They don't say which actors speak in which
order. I would say that they are more like data formats than protocols.
So we come back to your question: is sending PDF over HTTP a "new
protocol?"
[1] http://www.dictionary.com/cgi-bin/dict.pl?term=protocol&r=67
"A set of formal rules describing how to transmit data, especially
across a network."
> It is interesting that on the one hand folks would argue that actions and
> data should not be coupled, but on the other hand any modular vocabulary
> ever employed within a SOAP envelope must be viewed as just an extension of
> SOAP.
I'm struggling to see any relationship between the discussions.
> <snip/>
>
> > It is provably the case that POST is sufficient for the operation
> > because you are doing it.
>
> Bullshit. POST is simply sufficient to get the body of the message to the
> application that will process it.
Fine. POST is doing the job of a protocol. Getting data across the
network from the process that generated it to the application that will
process it. Thanks to URIs, you know what the POST's more precise
semantics are. There is no need to put behaviour in the content of the
message.
>...
> Yup. If you hack an HTML form and change it to send up parameters of your
> choosing, do you seriously expect that the receiving application can make
> use of them?
No. If you send the wrong data through a protocol then you are going to
break your application. If I send a string through an XML-RPC method and
someone else sends an integer, do we have two different protocols?
> .. The application serves up a form with specific parameters to
> the client, and it expects those paramters -- and no others -- to come back
> to it. You want to attach another name to this? Fine. I call it a protocol.
I don't want to attach a name to it. Why bother? Everybody understands
that HTTP is the protocol! Maybe I'd call it a "web app." It certainly
isn't a protocol.
> But certainly it is ridiculous to maintain that that data is meaningless and
> has no relevance to the interpretation of the message.
Who said either thing? The data has meaning. But it is different than
the protocol. Consider the following Java code:
class foo{
void doit(String action, Object arg1, Object arg2, Object arg3, ...){
if(action="calculate_factorial"){
return factorial((Integer)arg1);
}else if(action="calculate_sum"){
return (Integer)arg1+(Integer)arg2;
}
}
}
(let's pretend that Java was a Real Language, had varargs and could add
Integers)
Now if you were taught to program in this style, you might think it odd
when someone told you that there was really no need to dispatch on a
name passed as data. In fact you could move that out to the method name
(or in the case of the Web, to the URI/method combination).
>...
> Are you seriously contending that we now have all of the protocols we will
> ever need to do whatever we want in the computing world? We are all done and
> can all go home now?
Do we have all of the extensible, generalized markup languages that we
need? Are you spending significant amounts of your time researching
YAML, LaTeX and S-expressions?
A markup language is a way for expressing attributed trees. Once you've
done it once, the best you can hope for are incremental improvements in
performance or simplicity. IMHO, your time is better spent building
layers upon it. (call them vocabularies, dialects, extensions, whatever)
An application language is a way for moving data from place to place and
saying what to do with it. Once you've done it once, the best you can
hope for are incremental improvements in performance or simplicity. Your
time is better spent building layers upon it. (call them extensions,
dialects, protocols, whatever)
Of course there are performance reasons to bypass XML sometimes, and the
same goes for HTTP. But in my opinion, it would be insane and strictly
speaking incorrect to claim that XML is not sophisticated enough to
represent some sophisticated data, or the lambda calculus is not
sophisticated enough to represent some computation or that HTTP is not
sophisticated enough to represent some application's network
requirements.
> And all those J2EE servers being deployed could be replaced with servers
> that simply understand HTTP GET and POST?
J2EE is not a protocol. HTTP is most often the protocol that is used
with it.
>...
> Please don't start throwing titles at me. Titles don't impress me.
My point was just that Mark's job for the last several years has been
applying protocols to real-world problems. Your inference was that you
have Real Problems and that he is just a theorist. My claim is that he
has bet at least one, and probably two businesses on *software* that
implements this "theory" to solve real-world problems.
You'll notice that the chairman of the Apache foundation is also in the
business of solving real-world problems with HTTP. So is Rohit Khare, an
extremely smart ex-W3C employee. Another ex-W3C employee (Henrik
Nielson) is at Microsoft and perhaps coincidentally (I really don't
know) their .NET My Services protocol has only a very few methods that
map essentially to the HTTP methods (query, insert, replace, update,
delete). It isn't called HTTP because that wouldn't be cool but it is
essentially a variant of it reimplemented on SOAP. So they've added two
layers to the protocol stack to get back to the same place. As I've
demonstrated, UDDI did the same. Watching for this pattern in the
future....
>... I am just viewing this as
> a rather spirited debate, though I'll confess to some frustration trying to
> converse with folks who seem to think that rich distributed systems can be
> constructed using purely the semantics of GET and POST. The simple fact is,
> that is too constraining.
Actually, we advise using GET, POST, PUT and DELETE. As I've said, those
map to .NET My Services (which is intended to be a universal personal
data management protocol) but they also map to SQL's SELECT, INSERT,
UPDATE, DELETE. Is SQL too weak for real work because of its paucity of
methods? The Unix shell has >,<, >> and rm. The DOM has childNodes[x],
insertChild, replaceChild and removeChild. UDDI has get_*, delete_* and
save_* (it uses one less method...).
I don't think that this pattern is being copied from place to place. I
think it is a reflection of some fundamental laws of the universe. HTTP
is merely one expression.
But I don't want to focus too much on the methods to the exclusion of
the URIs. The URIs are as, if not more, important. It is the combination
that allows you to use generic methods and separate protocol and data.
Paul Prescod
|
