Re: [hybi] Framing proposal with start/end demarcation

[Roberto Peon <[e-mail]>]

On Thu, Aug 5, 2010 at 10:55 AM, James Graham <[e-mail]> wrote:

> On Thu, 5 Aug 2010, Roberto Peon wrote:
>
>  Google, Amazon, Rackspace, VMWare, 3Tera, whomever. I don't think this is
>> a solely a Google problem, I think we're just the first
>> to start thinking about it deeply.
>>
>
> Sure, I didn't mean to imply it was only a Google problem. But for many
> potential users it is not a significant problem.
>
>
>  Agreed. Is the argument then that we believe that supporting scalability
>> induces so much complexity as to cause failed
>> implementations?
>>
>>
> It is certianly true that trying to introduce significant complexity right
> now, i.e. in the probably-short time before we have shipping Opera, Firefox,
> Safari and Chrome all with WebSockets support, introduces a serious risk of
> bugs or partial implementations. In practice if the intersection of what the
> aforementioned browsers support is sufficient to be usable then it will
> establish an ecosystem that depends on that intersection continuing to be
> supported in the future, effectively creating a de-facto base protocol.
>

If I had a belief (or at minimum an assurance) that if there was a
continuing worry about scalability as we go forward that we would change the
protocol and get it implemented in Opera, Firefox, Safari and Chrome, I'd
not be making noise-- I'd be cheering! We'd be on our way to an
implementation-first, then standardize process.


>
> I also believe it is true that introducing significant mandatory complexity
> to servers at any time significantly increases the barrier to writing a
> server i.e. produces failed (potential) server implementations. It also
> increases the risk of bugs in servers which one could presume may manifest
> themselves as significant problems e.g. security issues.
>
> Although these are arguments against starting with something too complex,
> they are not the only arguments that have been made. For example it has been
> pointed out that by starting with something simple we can ensure that we are
> adding the only things that are really needed. In the "now" timeframe we
> don't have the ability to collect data about how to optimise for performance
> and scaling. If we give ourselves more time we can collect better data from
> real world use and end up with a better, more scalable, design in the long
> run.
>

This definitely works when the set of developers is small or well
controlled. We as a set of interests are not particularly well controlled,
and certainly the set of developers implementing this won't be small.
If Mozilla, Opera, Google, and Safari were all making their own variations
of their own versions of a standard, I'd believe that we could move forward,
because in the future it would be necessary to standardize.
We're upside-down right now. We're standardizing something that doesn't meet
the needs of entities that serve a large percentage of users with little to
no incentive to change that in the future.

What is the incentive for Mozilla, Opera, and Safari to change their
implementations again in the future? When will this happen?

We're not even talking about limiting the maximum number of concurrent WS
connections that may be created to a site (something which could be
extremely simple in the protocol and something which we've already done for
HTTP).
I'm worried that we're making it so simple right now because we're assuming
that the network and the servers will not be impacted negatively. I'm
worried that we will be negatively impacting the networks, the airwaves
(bandwidth consumption on phones for many multiples more keep-alives), etc.

To me, it feels a bit like global warming! :)

-=R