Subject: Re: [hybi] Divide and conquer?

From: John Fallows <[email-masked]>
Date: Mon, 4 May 2009 10:56:31 -0700

Greg,

On Thu, Apr 30, 2009 at 1:39 AM, Greg Wilkins <[email-masked]> wrote:
>
> John,
>
> I think this is a good plan, but with some caveats.

Great.

> The current websocket API is described in very network related
> way. Eg it is about opening connections and connection state etc.
>
> If the separation of concerns that you describe is to be successful
> then the websocket API is going need to be recast in less
> network centric language - ie saying channel/conduit/pipe or similar
> instead of connection.     From the API point of view, it should not
> matter if that channel/conduit/pipe is carried over a dedicated
> socket or some other possibly shared transport.

So far on the mailing list, we've been discussing a number of
different intermingled issues that contribute to this complex problem
space.
The steps outlined in the plan provide a common sense step-by-step
approach to help us solve this problem together.
Discussions related to the specific API that we'll define are more
productive after gaining the relevant insights from prerequisite
network characteristics, otherwise we run the risk eliminating the
benefits of our common-sense approach.

> There would need to be a good dialog between the API concerns
> and the network concerns.    Perhaps that could start by the
> API writing up some requirements that they would like the
> network concerns to provide.

I'm sure we'll be able to hear everyone's focused and constructive
feedback in the relevant threads.  Next up - the "Connection Strategy"
thread.

Kind Regards,
John Fallows.

> John Fallows wrote:
>> Folks,
>>
>> In an effort to help organize our thoughts and discussion, I propose
>> we divide the problem into chunks and tackle each one separately.
>>
>>   o Connection strategy - eg. crossdomain.xml + raw TCP, HTTP 101
>> Switching Protocols, etc
>>   o Proxy traversal strategy - eg. transparent proxies,
>> non-transparent proxies, reverse proxies, etc
>>   o Wire protocol - eg. raw TCP, text/binary frames, higher-level
>> messaging protocols, etc
>>   o JavaScript APIs - eg. event-driven data, notify then read,
>> higher-level messaging protocols, etc
>>
>> Does this seem like a reasonable separation of concerns that would
>> help us to make useful progress?
>>
>> Based on the separation of responsibilities between the IETF and the
>> W3C, it seems that connection strategy, proxy traversal strategy and
>> wire protocol would fall under the IETF whereas JavaScript APIs would
>> fall under the W3C.
>>
>> Therefore, assuming that the above separation of topics is useful, I'm
>> planning to wait a day or so to give folks a chance to respond, then
>> start a thread on each of the topics that pertain to the IETF.
>>
>> Kind Regards,
>> John Fallows.
>>
>> Disclaimer:  Kaazing currently offers (emulated) WebSocket-based
>> products that implement both the wire protocol (when possible,
>> otherwise fallback to HTTP) and JavaScript API from a draft of the
>> specification(s).  Our goal in participating with the IETF and the W3C
>> is offer insights gained from customer feedback to help standardize
>> the future of real-time communications on the Web.
>>
>
>

-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA