W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: URL.createObjectURL() for DataChannels

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 18 Jul 2013 06:38:18 +0200
Message-ID: <51E7713A.3000100@alvestrand.no>
To: "piranna@gmail.com" <piranna@gmail.com>
CC: Martin Thomson <martin.thomson@gmail.com>, Peter Thatcher <pthatcher@google.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc <public-webrtc@w3.org>
Piranna, now that I understand a bit better what you're driving at....

I think an URI for a data channel might be useful in some cases:

- Passing a data channel by reference between components inside a
browser. At the moment, we haven't talked about WebWorkers and WebRTC at
all; there are certainly things we can do if we can use WebWorkers on
PeerConnections and data channels - or even pass data channels between tabs.

- Plugging a data channel into some JS interface that expects some other
kind of resource. This would probably require some kind of wrapping URL
scheme (HTTP isn't one, which was what I was initially confused about),
and some careful consideration of semantics (data channels send
messages, not bytes, for instance), but could be useful.

Both of these are reasonable things to do within browsers; if I
understand you correctly, there isn't really an use case for passing the
URI of a data channel between browsers, since it refers to a local
object that can't be passed over the Internet.

Do I understand it more correctly now?


On 07/18/2013 01:09 AM, piranna@gmail.com wrote:
>
> Another (bit diferent) use case: since DataChannels API is inspired by
> WebSockets one, being able to use a URI and maybe also having a scheme
> (dc: the same way ws:) they would be easier interchangeable and being
> able to reuse code to be used both with connections to servers or with
> other peers just changing the URI.
>
> El 17/07/2013 18:06, "piranna@gmail.com <mailto:piranna@gmail.com>"
> <piranna@gmail.com <mailto:piranna@gmail.com>> escribió:
>
>     I didn't know about RFC 6920, but yes, the point is to identify each
>     object by their hash, both for anonimity and uniqueness. Regarding to
>     magnet links, some people proposed it to me several times, but don't
>     know how a browser would manage various webapps (a browser based P2P
>     like mine, a bittorrent client on the cloud, a DirectConnect client
>     installed on its machine...) registering for the magnet scheme...
>
>     Any way, thanks for remind us about them :-)
>
>
>     2013/7/17 Martin Thomson <martin.thomson@gmail.com
>     <mailto:martin.thomson@gmail.com>>:
>     > On 17 July 2013 00:58, piranna@gmail.com
>     <mailto:piranna@gmail.com> <piranna@gmail.com
>     <mailto:piranna@gmail.com>> wrote:
>     >> I've remember another use case I read some time ago, regarding
>     to use a P2P
>     >> URI scheme inside <video> tag sources:
>     >>
>     >> <video>
>     >>     <source src="p2p:123456789abcd"/>
>     >>     <source src="http:/dc:abcd1234/video.avi"/>
>     >>     <source src="http://example.com/video.avi"/>
>     >> </video>
>     >>
>     >> I find this very doable and with real use cases...
>     >
>     > RFC 6920 already exists.  It deals with the security issues that
>     > haven't been mentioned yet.
>     >
>     > Or, you could use what has actually been deployed:
>     > https://en.wikipedia.org/wiki/Magnet_URI_scheme
>
>
>
>     --
>     "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>     monton de sitios diferentes, simplemente escribe un sistema operativo
>     Unix."
>     – Linus Tordvals, creador del sistema operativo Linux
>
Received on Thursday, 18 July 2013 04:38:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC