Better Event Names for call:started and call:ended

[DamonOehlman]

I just had a good discussion with @pedalpete regarding the event names of call:started and call:ended. He expressed some confusion when writing a multiparty application with regards to the call:started event and how it possibly relates to the way we are thinking about the app.

For instance in his app, he considers the first connection made to a peer being the time at which a "call" is started, and subsequent peers are then joining that existing call. Thus he was surprised when he got additional call:started events. I think this is completely reasonable and logical thinking.

One possibility is to move the names to something like the following (which I think is in line with a suggestion made by @balupton some time ago):

• call:started => peer:connected
• call:ended => peer:disconnected

One thing to be aware of is that there is an existing event peer:connect which does cause us a bit of an issue, but it might be worth making the change if it makes more sense in the long run. Additionally, the existing peer:connect and peer:couple events are more informational events though could be used by people so we are definitely talking a major version bump for quickconnect (and a well documented one at that).

These existing events could be changed to the following:

peer:connect => peer:connection:create
peer:couple => peer:connection:couple

With all of these potential changes, it would move a lifecycle of (major) peer events within a quickconnect driven application to something that looked like the following:

• peer:announce - a remote peer has announced themselves on the signalling server
• peer:connected - a peerconnection has been established from us to a remote peer
• peer:disconnected - a peer connection has been terminated with a remote peer
• peer:leave - a remote peer has disconnected from the signalling server

NOTE: The order of the final two events does not have to occur in that order, for instance it is possible for a peer to disconnect from the signalling server and for us to hold a peer connection open to the peer.

[nathanoehlman]

I'm definitely in favour of this - I think that while the `peer`` events that you've listed above aren't providing an extra details, it will provide a lot more clarity as to what is happening - particularly to new rtc.io users.

[silviapfeiffer]

@nathanoehlman leaving this open for you to address if and when it pleases you. :-)