On Thu, May 27, 2010 at 9:26 PM, James Salsman <[email protected]> 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
