Don't require &mut self for WebRtcSocket::id, players

[johanhelsing]

in #111, id and players started taking &mut self and returning Option<PeerId> instead of &PeerId.

This made the socket a bit more awkward to use. This fixes the &mut self part of it, though you'd still have to deal with the case when socket.id() returns None.

Alternative to #136

[garryod]

This is a nice improvement to the ergonomics. Whilst it would be nice to be able to guarantee an Id in the future this seems like a far better interim solution than the one I had

[johanhelsing]

Okay, merging this. I'm not necessarily opposed to #136 , but I'd like some solution that makes it less awkward to use with bevy, but not exactly sure what that would be...

[garryod]

Okay, merging this. I'm not necessarily opposed to #136 , but I'd like some solution that makes it less awkward to use with bevy, but not exactly sure what that would be...

A few thoughts:

• Ultimately there's always going to be the sync/async boundary to contend with when it comes to bevy.
• Exposing async higher up is almost always nice when the user is working in an async context.

Perhaps the solution is to provide a bevy Plugin that creates the "socket" resource for you allowing us to hide the ugly async bits

[johanhelsing]

Perhaps the solution is to provide a bevy Plugin that creates the "socket" resource for you allowing us to hide the ugly async bits

Yes, something like this feels like the right thing to do, but I find it hard to decide until we've actually tried doing it...

[simbleau]

Perhaps the solution is to provide a bevy Plugin that creates the "socket" resource for you allowing us to hide the ugly async bits

Yes, something like this feels like the right thing to do, but I find it hard to decide until we've actually tried doing it...

Honestly I have this pretty much written already for my own game client. I could submit a PR with my abstraction layer. I put a snippet in #136 for viewing. Basically all I do is make the socket a resource and then have the plugin listen for Connect/Disconnect events. On connect, it attempts to create the socket, and if successful will start firing all the socket updates as events.

That basically means as a user you're responsible for 2 things:

• Sending the event when you want to connect/disconnect
• Listening for socket events in Bevy

[johanhelsing]

Discussion continued in #144