Re: What is missing for building "real" services?

> * It is too much cumbersome to create a DataChannel-only connection and
> there are too much concepts related to it: SDP, offer, answer,
> PeerConnection objects, signaling channel (common sense says, if you already
> has a channel to comunicate between both peers, why you would create another
> one)... Too much complicated and anti-intuitive.
>
>
> Signaling often (almost always) is relayed by a 3rd party, perhaps even
> cut-and-paste in IRC.  The SDP (and ICE, etc) lets the two sides negotiate a
> direct p2p connection.  Plus pure p2p data connections simply falls out of
> the work done to provide audio and video (and data) p2p.  If you're building
> a pure data application, most of these things (SDP, etc) don't need to be
> understood or examined, just treated as black boxes of setup data to be
> exchanged.  (The fly in the ointment is as you mention later Trickle ICE,
> though there are reasons for it even in .)
>
I'm mainly focused on pure P2P data connections, so treat this data as
black boxes is somewhat ugly, but acceptable (just live with it ;-) ).
The point about Trickle ICE is more annoying, specially being Chrome &
Firefox accepting different directions on this point. I believe the
best for all would be to add a flag on the PeerConnection object so
Trickle ICE could be enabled or not, and in this case I find
acceptable (and also desirable!) that if so, Trickle ICE is enabled by
default. It could also not only simplify some use cases like the mine
(pure P2P data connections) but also help on debugging (disable
Trickle ICE and looks what being generated on one point).


> * Also, you need to deal with candidates and Trickle ICE (the epithome of
> anti-intuitive things for a web developer, my DataChannel-polyfill developed
> using the firts specs didn't need it and was fairly easy to understand how
> it worked and straighforward to implement, but adding support for candidates
> was a nighmare both on usage and implementation), that although you can
> override it just waiting all candidates to be generated when onicecandidate
> event gets null, it is more like a hack that a real solution, while there
> should be an option about to use Trickle ICE or instead receive the full SDP
> when calling createOffer() and createAnswer(), that in that case would
> simplify (somewhat) it's usage.
>
>
> This touches a fundamental area of contention in the spec - complexity
> versus capability.  For audio/video (and also data), speed of negotiating a
> connection may be a very important thing, and trickle can help here.
> However, especially for non-interactive acceptance (which will be much more
> common with data-only connections), the advantage of trickling candidates
> goes down.
>
Totally according to this, that's why I said that if giving the option
to use it, Trickle ICE should be enabled by default. In my use case,
data-only connections will be created automatically on background
(that's why I also proposed about being able to create them from
inside Workers), and negotiation time is almost totally irrelevant
here.


> * There's no way to get a list of all the DataChannels being used on a
> PeerConnection object, while there are lists for the audio & video streams.
> DataChannels specification is almost one and a half years old, why it hasn't
> been added yet?
>
>
> The API for adding and removing datachannels is not the same as for adding
> and removing MediaStreams, which is part of the reason.  To be honest, no
> one has seriously proposed a use-case for needing it.  Given the low
> likelihood of an application needing this, letting the application keep the
> list itself (if it needs to) seems reasonable.
>
Ok, here you have mine: http://shareit.es, a serverless P2P
filesharing application using DataChannels and it's underlying
hadshake library http://webp2p.io. They are currently being reworked
but I could be able to show it's possible to do it (I won the "most
innovative project" last year on the spanish Universitary Free
Software Championship).

My need for a list of DataChannels in a PeerConnection object it's
just because on WebP2P.io the PeerConnection objects create a
distributed P2P network using the DataChannels, being one of them for
doing the P2P signaling and leeting the others for
application-dependend sub-protocols: HTTP, FTP... whatever. So, I need
the list not only to know what are the services being used between two
peers, but also to know when there are no more ones and I can delete
the PeerConnection object.

I've done a shim that enable this functionality, the API is based on
the current one for getLocalStreams() and getRemoteStreams() on the
WebRTC specification, this is the code to enable it:

/**
 * Add support to get a list of channels on a PeerConnection object
 */
function applyChannelsShim(pc)
{
  if(pc.getDataChannels != undefined) return;

  var channels = [];

  pc.getDataChannels = function()
  {
    return channels;
  };

  var dispatchEvent = pc.dispatchEvent;
  pc.dispatchEvent = function(event)
  {
    if(event.type == 'datachannel')
    {
      var channel = event.channel;

      channels.push(channel);

      channel.addEventListener('close', function(event)
      {
        channels.splice(channels.indexOf(channel), 1);
      });
    };

    // Dispatch application datachannel events and regular ones
    dispatchEvent.call(this, event);
  };
};


> * Finally, nothing has been talked officially about add support for
> PeerConnection inside WebWorkers (specially SharedWorkers or the upcoming
> ServiceWorkers), when it would be useful for maintain connections open or to
> do transfers on background.
>
>
> This has been mentioned.  This is not necessarily simple, though I agree
> there are significant advantages to making it possible.  I would not expect
> it in the first iteration of WebRTC/PeerConnection.
>
It's sad to hear this :-(


-- 
"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 Monday, 6 January 2014 17:38:13 UTC