Subject: [hybi] Divide and conquer?

From: John Fallows <[email-masked]>
Date: Wed, 29 Apr 2009 12:07:24 -0700

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

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 29 Apr 2009 21:32:19 +0100

> non-transparent proxies, reverse proxies, etc

These seem to be completely independent of the Javascript APIs as far
as I can tell.  As long as they can deliver a two-way message or byte
stream.  Both look tremendously useful for any other protcols being
tunnelled over HTTP too, not just WebSockets.

> higher-level messaging protocols, etc

These are mutually dependent because the current Javascript API
requires the protocol to have delimited message boundaries, so general
"TCP style" byte stream is not an option with the current API.

> help us to make useful progress?

I think it's an excellent separation.

I'm not sure if the following is subsumed under wire protocol.  It's
an issue with practical implications, though interestingly needn't
affect the API, but may affect users of the API:

   o Connection merging - wire-level multiplexing or many separate
     connections, aggregation at proxies, framing and flow control.

> wire protocol would fall under the IETF whereas JavaScript APIs would

The Javascript APIs cannot be developed entirely independently of the
wire protocol for the reason given above: the _current_ Javascript API
may/may not require the protocol to have self-describing frames, and
hence be incompatible with a general "TCP style" byte stream which
does not have message boundaries.

Maybe we'll settle on an extensible protocol with a well-defined
"profile" of capabilities which is accessible to the Javascript API.

I think the IETF people are ideal for addressing the networking
issues, and W3C people are ideal for designing a good Javascript API
for ordinary web developers; that looks like a good plan.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 30 Apr 2009 18:39:53 +1000

John,

I think this is a good plan, but with some caveats.

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.

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.

cheers