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

On Wed, Jan 23, 2013 at 8:42 PM, Greg Wilkins <gregw@intalio.com> wrote:
> On 12 January 2013 07:05, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> [...]
>
> -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.

Be careful about multiplexing different qualities of traffic over a
single TCP connection.  You don't want to have the SSHv1 flow control
problems all over again.  You also don't want to replicate SSHv2's
answer to those problems.

Basically, you should want one connection for bulk-ish traffic, and
one for non-bulk-ish traffic.  Else bad.

Nico
--

Received on Thursday, 24 January 2013 18:26:39 UTC