Re: Alternative data API

On 01/30/2012 09:59 AM, Randell Jesup wrote:
> On 1/29/2012 11:28 PM, Stefan Hakansson LK wrote:
>> On 01/30/2012 02:32 AM, Justin Uberti wrote:
>>>      I assume that you're talking about multi-user with a central server,
>>>      otherwise there would be a separate PeerConnection to each user.
>>>      With the "Alternative Data API" muxing of DOMString data is
>>>      straightforward (to do in the application); blobs and ArrayBuffers
>>>      is another story. There ChannelMessaging should be possible to use
>>>      to create channels, but I've not looked into the details (and am
>>>      unsure about the maturity of ChannelMessaging).
>>> It's multi-user that is not full mesh, but it might not involve a
>>> central server (e.g. a directed p2p graph).
>>> If all the elements in the graph are aware of the application protocol,
>>> this would certainly work, even with ArrayBuffers. The app could create
>>> its own packet format, and use that to create its own multiplexing
>>> mechanism, and even its own reliability and priority mechanism (it would
>>> of course have to depend on the PeerConnection's congestion control
>>> mechanism).
>>> This might allow us to make the in-browser code substantially simpler,
>>> as it would just be a secure pipe for generic datagrams at this point.
>>> All the advanced stuff would be done through JS libraries.
>>> I think this is a important point for the WG to consider. Would folks
>>> rather have a simpler, less capable API that we can ship sooner?
>>> I admit that doing SCTP or PseudoTCP in Javascript sounds interesting.
>> I must admit I never thought that far. My idea was more to have a
>> simple API (much aligned to WebSockets) for a start, and then add
>> functionality if needed (with e.g. the options argument); but having
>> SCTP as the underlying transport.
>> I think that also with the simple start API you can get a lot of
>> functionality by combining it with other tools in the web platform
>> (and the app can perhaps prioritize between its own data).
>> But I think your question (i.e. doing protocol in JS) is valid indeed.
> It's interesting, but to me this is backing into what we rejected early
> on - encouraging/forcing app writers develop their own reliability
> protocols on top of a DTLS/UDP datagram transport.  Whether these are
> "shared" JS libraries or plain JS code in the app, there still will be
> the problems that apps have with JS libraries - correctness, bugs,
> updates (and maybe speed).  People normally snapshot a version of the
> shared JS lib, and may fork it; in either case they often never or
> rarely update it.  You may (probably will) get several competing
> implementations with compatibility issues.  And that assumes a single
> "gold-standard" JS reliability app pops up with a high-quality impl; if
> that doesn't happen, it's a *real* mess.  The only positive I see is
> that bugs in the protocol are more likely to be contained, and not the
> source of security bugs.

Speaking as individual: I largely agree to this.

Perhaps we could incorporate the entire SCTP stack from day one (if it 
is as you say that it is not that much of an effort), but not expose all 
functionality in the API. This would give as an easier journey to data 
support (because it is a lot of work to design, and spec, those APIs; 
doing a simple API could let us re-use a lot of what is already there 
for e.g. WS), but allow for exposing more functionality in the API as 
there is requests (nothing would break since old apps using the initial 
API would still work).

> I think you're much more likely to get stuff reliable and complete (and
> *properly* used by app developers) by incorporating into the browser a
> known solid SCTP impl, and regularly updating it (we could probably do
> so for each Firefox "release train" every 6 weeks).  We know app
> developers (especially in gaming) will want these functions ASAP.
> Obviously there are tradeoffs, but I don't think incorporating SCTP is
> going to slow things down *that* much.
Speaking as individual: I largely agree to this.

Received on Tuesday, 31 January 2012 13:27:00 UTC