search

johanhelsing / matchbox

Painless peer-to-peer WebRTC networking for rust wasm (and native!)
Apache License 2.0
869 stars 72 forks source link

Improve or remove `ChannelPlurality`? #332

Open simbleau opened 11 months ago

simbleau commented 11 months ago

I'm not sure if anyone would agree, but I see the plurality as an ergonomic papercut on API usage, especially in Bevy.

commands.open_socket::<MultipleChannels>() and commands.close_socket::<MultipleChannels>() require generics, etc. which doesn't feel at all right.

I don't want to remove the SingleChannel API, since I think it's very helpful.

Perhaps the solution would be to make different traits that can be imported for Bevy? e.g a ComplexSocketExt trait and a SimpleSocketExt which assume the plurality?

johanhelsing commented 11 months ago

I'm still not entirely convinced that the command extensions are a good idea... even though I think it was I who suggested it. It limits the API to a single socket, allows calling close_socket when there is no socket, what happens when you open and there already is a socket?

Operating on Resources/Components isn't much more complex and makes it a lot more flexible and makes it more understandable what actually happens?

simbleau commented 11 months ago

Yeah, I agree.

simbleau commented 10 months ago

Ok, let's remove the Command extensions for now. I agree with the resource-driven approach.

re: generics, are we expecting users to do something like this, assuming they want to stay DRY? I'm still not totally satisfied with it, but I'm ok with it.

type MySocketType = MatchboxSocket<SinglePlurality>;
...

app
   .add_plugins(...)
   .init_resource::<MySocketType>();
...
   .remove_resource::<MySocketType>();