Re: [hybi] Requirement: extensions and sub protocols

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> 
> I think we need to decide who will be doing the extending
> and creating new subprotocols.
> 
> Ian appears to be advancing the position that if it can't
> be done in javascript via the websocket API, then it can't
> be done.  Moreover, that if you are not doing it in javascript
> then you shouldn't be using websockets.
> 
> 
> I disagree with that position (which is hopefully
> somewhat close to what Ian actually is saying).

I'm a bit confused about what Ian's saying in that regard, so I don't
know if it's close or not :-)

But anyway, my position is this:

   - If it *can* be done in Javascript via the API, that's a good thing.
     It means the API is versatile enough.

   - The API isn't relevant to non-browser agents, and constraints
     implied by the API don't affect them.  Only the protocol matters,
     so all constraints affecting the protocol should be written in the
     protocol spec, not inferred from the Javascript API.

Categories:

   1. Some extensions really should remain in Javascript.  There is no
      advantage to complicating the browser for them.

   2. Some extensions are *better* if done by the browser, but it is
      still good to have the ability to fall back to Javascript on an
      older browser.  Multiplexing connections from a single tab/window
      falls into this category.

   3. Some extensions cannot be done from Javascript at all.
      Opportunistically multiplexing connections from all tabs/windows
      to the same destinations (or proxy if there is one) falls into
      this category.  Practically, certain buffering strategies fall
      into this too, but hints from Javascript may be valuable.

It might be good to identify which extensions fall into each category.

Right now, all the extensions involving binary frames and chunking
have no relationship with the Javascript API at all, because it
doesn't support those frames.  It's not clear what the future plan is
for this.  Therefore it's not clear which category they'd fall into.

>   Firewalls acting as aggregators and combining
>   multiple base connections into fewer multiplexed
>   connections to the business servers.
> 
>   Appliances doing SSL offload and converting wss to ws
>   connections with injected certificate information.

These two go well together, by the way.  Fewer connections means fewer
SSL negotiations.

> I also think that there will be extensions done
> in javascript by frameworks/applications, but by
> definition they work above the API and need no more
> support from the base protocol than the API already
> provides.

However, if the base protocol grows some things which help
non-Javascript extensions, such as the chunk no-delay flag we've been
discussing, in some cases it may be useful to expose those
capabilities to Javascript as well.  E.g. I can think of a few games
writable in Javascript which could benefit from that.

-- Jamie