Re: [hybi] how do we move forward on agreeing on framing?

[Roberto Peon <[e-mail]>]

On Thu, Aug 19, 2010 at 10:15 AM, Francis Brosnan Blazquez
<[e-mail]>wrote:

> >         I think it is taking to much attention to include advanced
> >         features in
> >         the base protocol, or to define extensions that allow them,
> >         especially
> >         when those features can be implemented by protocols already
> >         defined like
> >         BEEP [1].
> >
> >         I'm sure many people is expecting to access to a simple
> >         protocol that
> >         allows direct connection and bidirectional content transfer
> >         from the
> >         browser. Nothing else.
> >
> >
> > That is true for the API users. The people who have to implement this
> > en-masse and at scale have additional requirements.
>
> Certainly, if we assume websocket should also solve requirements that
> may be implemented by other protocols on top of it.
>
> > We've torpedoed multiplexing for now (and multiplexing is the one
> > thing that can help scalability here).
>
> I don't think so. By making websocket simple and leaving room to
> application protocols on top achieves both goals: you still can do
> multiplexing and your transport protocol keeps simple.
>
>
Not everyone who is scaling things has control over both endpoints, thus
that layer of application protocol is inaccessible for these needs.


> > Ok, so then we need an extension mechanism in order to implement and
> > experiment with enabling multiplexing.
>
> BEEP already provides channel multiplexing and profile selection and it
> can be layered on top of websocket. This can provide the scalability you
> are looking for without compromising the base protocol.
>

I don't think that is the case since I'm likely to have to load-balance
millions or billions of connections and not have the ability to modify or
place interesting requirements on the servers while remaining competitive.
-=R


> --
> Francis Brosnan Blazquez <[e-mail]>
> ASPL
>
>