Re: [hybi] updated Charter proposal (WebSocket)

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

> However, the draft itself has changed a lot in response to feedback over 
> the years. 
>
> I don't adopt every proposed change, sure, but I think I have shown myself 
> to be quite willing to change the proposal based on reasoned arguments and 
> clearly demonstrated needs and problems.

My apologies - I probably over stated the case that the ws authors
are resistant to  change.

I think it is more accurate to say that you are more resistant to
requirements other than your tight focus on a minimal protocol to
enable a close socket equivalent to js running in a browser.

I think resolving the differences in requirements is the prime
task the IETF WG will have.     Once their is rough consensus
on the requirements - most of the protocol design is a matter
of style.


>> So will the WG have the ability to come up with it's own draft for a 
>> websocket protocol - or will all it be able to do is huff and puff and 
>> hope to convince the whatwg?
> 
> Say the WG adopted BWTP as the basis for its work. Will you drop 
> Multiplexing and MIME typing from the BWTP proposal? If not, does that 
> mean you are resistant to change and then will the WG only be able to huff 
> and puff and hope to convince you?

I'm not proposing that BWTP is written into the charter as the
only possible option.

I don't really care what protocol is accepted, so long as it
makes my job as a comet infrastructure developer easier.
For me this means:

+ abstract applications developers away from TCP/IP
  connection management
+ minimize connection growth on the server side
+ allow for flexible and extensible usage.
+ allows intelligent intermediaries to participate
  (load balancers, concentrators, SSL offloaders etc.)

BWTP attempts to meet those with channels based multiplexing and
support for mime encoding.    But there are many ways to solve those
and my first preference was to enhance the WS proposal.   BWTP
was only developed as an alternative because WS just does not
address any of the pain points I have as a comet server developer.


> I don't mind what the working group works on, but if it's not that, then 
> it's not a working group I'm interested in working with, as it wouldn't 
> be addressing the needs that I'm trying to address.

So perhaps we have wasted a lot of time debating protocol design,
when we should have been discussing protocol requirements.

Then maybe we need two WGs and 2 protocols?


regards