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

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/