Plans to support multiple rooms? about protoo HOT 7 CLOSED

protoo is not intended for having the same user into N rooms. It's intended for real-time rooms (typically with audio and/or video) which means that the concept of protoo user is 100% tiled to a specific participant into a specific room.

from protoo.

Hey @ibc, I think you misunderstood my question. I was just wondering if you had any philosophy on how to keep track of multiple rooms on the server, (since there are no examples) NOT multiple users in multiple rooms. I checked out the tests and saw that you declared the room object in the global scope of the server.

Ideally what i'm looking for is a way for one type of peer to dynamically create rooms, and having another type of peer that can join these rooms. Of course I can create a Map that map arbitrary ID's to rooms and use this as a lookup when a Peer wants to join a specific room.

But because there is no ID or name property on the Room object, and thus no way to distinguish them (except for wrapping them in some other object) I was wondering what you're thoughts are on this topic.

Just for clarification, I intend to use your library for a webrtc application and liked the minimalistic approach you went for (without already forcing certain webrtc functions in the API).

from protoo.

The way I use it is by wrapping the protoo room into another higher level object in which I also manage other stuff.

I'm open to have a id lookup in the API. Is that really needed for your use case?

from protoo.

For my use case yes, but for now I'll probably just stick to using a simple map-wrapper higher level object. I think what is more important right now is having some more examples on how you think people should use the library. You're doing some good work but it's kind of unclear how we should use it :)

from protoo.

I agree more examples would be useful, but I don't think I'll have time to add them within the next weeks. BTW here how I use it:

https://github.com/versatica/mediasoup-demo/tree/master/server

from protoo.

Wow, I just checked it out and it is surprisingly close to the implementation I currently have. The only thing what I'm struggling with is the initial request and passing in data. Right now you pass in that peerId and roomId via the query params, which to me feels not ideal. What if we want to send some type of configuration object using a POST? right now the only way to pass information is using query params.

As for your time, if I have a better idea of how all of this works I might be able to help you out with examples. I'll keep an eye on this repo for now.

from protoo.

Placing custom params in the URL query of the WebSocket handshake is up to the developer/application. It could be ideal or not depending the use case.

In my case I want a fast validation of the participant so I use those query params to authorize or reject the protoo WebSocket connection. Yep, it's just a demo so there is no auth other than checking valid roomId and peerId.

Of course this could be done in any other way (such as allow any protoo WebSocket connection like if it was just a TCP connection, and rely on a subsequent protoo message with auth/identity info). Or, you may use an initial HTTP API request against the same domain for authentication purposes, get a token or a cookie, and rely on such a token or cookie for subsequent protoo WebSocket authorization.

I just don't want that protoo itself enters into that business. protoo provides a simple way to accept or reject a WebSocket connection (it allows async verification). Anything else is up to the app.

from protoo.