Re: Should Web Services be served by a different HTTP n+1?

[Greg Wilkins <[e-mail]>]

On 12 January 2013 07:05, Phillip Hallam-Baker <[e-mail]> wrote:

> Now it is pretty clear that port 80/443 is going to have to support both
> sets of use cases and Web Services have to tolerate being molested by
> intermediaries trying to address Web browser considerations. But other than
> that, the two sets of use cases seem pretty disjoint to me. We have already
> hived off Web Sockets as what is essentially a completely different
> protocol, perhaps it would be better to do that with Web Services as well.



-1

It is already extremely difficult that we have to run at least 3 families
of framing protocols, with many version varieties over ports 80/443:   HTTP
(0.9, 1.0, 1.1), Websocket (pre RFC and post), SPDY (v2, v3)   and soon
HTTP/2.0

I'd like to see the future of port 80/443 to be convergence of framing
protocols rather than divergence.   Specifically I would like to see that
rather than send the websocket semantic over its own framing layer that
HTTP/2.0 will be able to provide a framing layer that will satisfy both
HTTP and websocket semantics.

If webservices cannot be catered for by either of those semantics (and I
have my doubts as I think muxed HTTP is a pretty good match), then perhaps
there could be an argument to propose another semantic to be carried by the
same framing layer.

Note that one of the attractive features of Microsofts counter proposal to
SPDY as the basis of HTTP/2.0 was that it used the websocket framing layer
as the basis for a HTTP semantic binding.    I fully accept that we have to
upgrade 80/443 from HTTP/1.x framing to something else, but let's make that
something else support all the semantics we need rather than reinventing
framing for each and every messaging semantic.

regards



-- 
Greg Wilkins <[e-mail]>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.