[whatwg] <device> element, streams and peer-to-peer connections

[Mark Frohnmayer]

On Thu, May 27, 2010 at 9:26 PM, James Salsman <jsalsman at gmail.com> wrote:
>
> Would it be appropriate to allow selection between reliable delivery
> involving delay and unreliable delivery with the shorter delay
> characteristics of UDP by allowing the user to select between the
> TCP-based asynchronous HTTP/HTTPS multipart/form-encoded POST of input
> type=file accept=audio as per http://www.w3.org/TR/device-upload and
> use UDP for synchronous or asynchronous device element I/O?

I can see use cases for both methods -- a voice mail, server based
application could use a simple form submit upload, but a live voice
conferencing app would need real-time access more like in the Capture
API that the W3C DAP group has published:
http://www.w3.org/TR/capture-api/ .  As they've laid it out, capture
of audio/video is decoupled from the network transmission/streaming of
the captured data, which makes sense.  The media file data captured
could then be sliced into blobs and bounced off a server via WebSocket
or sent to peers via the peer to peer API.  Again here it would make
sense to me to pattern the p2p API more closely to WebSocket (i.e.
send packets of bytes) than a higher level approach that tries to
multiplex streams of data.

- Mark