Re: [hybi] [Uri-review] ws: and wss: schemes

Jamie Lokier writes:

> Secondly, this thread has talked about protocols on top of protocols
> (because every WebSockets application will be one).  Given a URI, you
> cannot tell from Content-Type whether that URI supports WebDAV, and
> you cannot tell whether that URI accepts POSTs to submit new blog
> entries - just to pick two widely used examples.
> 
> That requires another level of descriptive metadata

You're pointing out that the Web doesn't use static interface 
descriptions, except insofar as the rules for HTTP and URIs are set out in 
advance.

On the Web, you don't ask for static metadata that answers the question: 
"if I were to try a WebDav HTTP method on URI X, would it work?"  You try 
it.  HTTP tells you whether it worked, and if it did, gives back 
information that is interpretable (relatively) unambiguously per the 
specifications for URI (RFC 3986), which delegate to HTTP (RFC 2616), 
which in turn delegates to the media-type registration for the 
Content-type, etc.

FWIW: Web Services with WSDL take the opposite approach.  Web services do 
tend to emphasize static interface descriptions, advertised in advance. 
While there's endless gnashing regarding the pros and cons, it's along the 
lines of:  advance descriptions can be aids to tooling, debugging, and 
sometimes optimization, but dynamically negotiated contracts are usually 
more flexible.  In particular, I don't think the Web would work nearly as 
well if each URI had to advertise in advance:  "if you try a GET, I'll 
support it, and you'll get an image/jpeg".  Just do the GET, or WebDav, 
and see what happens.

Anyway, I thing we should wrap up this aspect of the discussion.  There 
are indeed some interesting questions as to how self-describing the 
websocket protocols should be, but here I think we're mainly concerned 
with the choice of URI scheme. 

Noah


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 19 August 2009 19:12:33 UTC