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

[Roberto Peon <[e-mail]>]

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

> On 08/05/2010 05:19 PM, Roberto Peon wrote:
>
>>
>>
>> On Thu, Aug 5, 2010 at 8:08 AM, James Graham <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>    On 08/05/2010 04:55 PM, Roberto Peon wrote:
>>
>>
>>        So, playing devils advocate, why are we implementing any framing
>>        at all?
>>        It is trivial for an application developer to do framing themselves
>>        (they can do length prefixing as a string, they can do sentinel
>>        demarcation, etc, etc.).
>>        Why aren't we waiting to see a strong need for this from the
>>        application
>>        developers?
>>        Now I don't really think that a lack of framing is a good thing,
>>        but if
>>        we're applying this litmus test we should apply it to all
>>        features, not
>>        just the ones that I want! :)
>>
>>
>>    Because we can't have a sensible javascript API at all without
>>    making the protocol message-based. In particular a typical
>>    sockets-style API with blocking .recv() calls doesn't play well with
>>    browsers (you don't want to let people block the UI thread). Since
>>    the API has to be asynchronous, making it messaged based and using
>>    events flows very naturally from the basic requirements.
>>
>>
>> Why not do it in a Worker and provide the appropriate JS which sets this
>> up automatically?
>> Or, why use blocking recv() calls? Use nonblocking recv()!
>> This would result in a far more simple protocol at the cost of moving
>> complexity to the application writers.
>>
>
>
You cut off the part where I said that I thought that the above was a bad
idea, BTW :)


>
> Sure. But everyone seems to agree that this makes the protocol gratuitously
> difficult to use. And that difficulty applies to everyone who wants to use
> it, which makes it relatively bad compared to something that only affects
> people working at scale.
>

Agreed, but with the coloring that we've been talking about the application
developers instead of the users. If users don't get to use WS to places that
need to scale, then we're penalizing a large segment of the user population.


>
> So, for every possible feature we have to make some judgment call on
> whether we want to support it and if so how. It comes down to weighing up
> the costs of the additional complexity, against its usefulness against the
> value to authors, taking into account at every stage that we could be wrong
> about the value if we have insufficient evidence to support the value
> proposition.
>
>
Understood.


> I don't think there is a simple litmus test that will tell us unambiguously
> what choices to make. But I do think that if you start simple and build up
> then you are sure to end up with something that at least works in the simple
> cases, and, as you identify more pain points (in usability, performance,
> etc.), you will cover more and more requirements with relatively low risk of
> being wrong. If you try and bake in lots of things from the start you run a
> high risk of being wrong about how the future will pan out. You also run a
> higher risk of buggy or incomplete implementations since implementers have
> more to do all at once. There is,some risk that future additions to the core
> never take off in the same way as the basic protocol. One would imagine that
> as long as we are really adding features that people want, the only barriers
> to adoption would be technical.


Well, unfortunately we know that isn't true. As we already know it is fairly
difficult to get all the browsers updated to something that speaks a new
protocol. Servers are a far easier chore to upgrade as there are far fewer
controlling parties. The technical challenges are the easy ones-- getting
users to upgrade or change their browsers is fairly difficult. If that
wasn't true there wouldn't be a significant population still using IE6 on
XP.


> So it is important to avoid such technical barriers upfront. Otherwise
> making small iterations should make the lack of a simple litmus test for
> determing which features will be needed in the future less significant.
>

I hope you're right. I'm afraid you won't be--  scaling is not optional. We
may not be able to use websockets if we can't get it to scale efficiently,
and I'm truly afraid that moving the complexity of multiplexing to the JS
applications will fail. And our ability to do that is limited to Google
owned properties.

So, what is the litmus test? I think that we should be thinking about the
users of the browsers in addition to the application developers, but I
haven't seen many mentioning anything like this explicitly.

-=R