W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 24 Jan 2013 10:20:57 -0500
Message-ID: <CAMm+LwhJvSXgPzdqv2GscD-mfR4O7R_bba5JnAbdmP+uR+6SYA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
If people don't want there to be two different families then I think the
header compression needs to be totally rethunk.

I do not want to have a compression library in my Web Services. Too much
code bloat and more importantly, too much memory overhead and too much CPU.

If we want to have a single protocol then maybe what we should be thinking
of is using the coap codes as the starting point for header tokenization.

On Wed, Jan 23, 2013 at 9:42 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 12 January 2013 07:05, Phillip Hallam-Baker <hallam@gmail.com> 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 <gregw@intalio.com>
> http://www.webtide.com
> Developer advice and support from the Jetty & CometD experts.
> Intalio, the modern way to build business applications.




-- 
Website: http://hallambaker.com/
Received on Thursday, 24 January 2013 15:21:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 15:21:30 GMT