Dynamic namespace support

[pobk]

Is your feature request related to a problem? Please describe.
I am unable to instantiate a server that is capable of accepting connections to dynamically assigned namespaces however the Socket.IO JS implementation supports Dynamic namespaces on the server through the use of th io.of(/^\/dynamic-\d+$/) construct. The specific use-case I have is related to a real-time case management platform in which many organisations participate, yet need to be held as secure and separate enclaves and silos. Each organisation uses, on average, 4-10 queues to process information. On top of this each open case establishes a SocketIO room to group updates to cases for subscribed parties.

On average, the platform has ~600 rooms active.

Describe the solution you'd like
This is probably best implemented as part of the Namespace classes instead of trying to bend heads around the non-class based implementations.

Ideally, at a minimum, the Namespace class could provide a regex property which could be validated against the incoming packets. However, the perfect option would be to utilise a callable on the namespace instance that provides a true/false response as to whether it elects to participate in processing the packet received.

Describe alternatives you've considered
I have been using rooms to separate these silos, however, the code to manage all the rooms, connections and routing is extremely complex. It structurally means I have to validate every request for authorisation to join, leave and send to every room.

A separate namespace would mean a vast reduction in the number of checks to perform. Furthermore it would simplify my architecture considerably as the namespace only needs to query the database for it's specific organisational records.

[miguelgrinberg]

This is probably best implemented as part of the Namespace classes instead of trying to bend heads around the non-class based implementations.

This isn't a definitive no, but I would prefer that whatever implementation is made for dynamic namespaces it covers both decorated and class-based usages. It should also handle both the sync and async servers or else I won't accept it.

However, the perfect option would be to utilise a callable on the namespace instance that provides a true/false response

That could work, and maybe the same idea could be applied to decorated handlers.

A separate namespace would mean a vast reduction in the number of checks to perform.

I disagree. It would reduce the checks that you do on your application, but those checks will not just disappear, they will be moved into this package. If that causes the server to slow down for everybody, then it wouldn't be a great solution. The vast majority of my users do not care about namespaces, they just use the default one.

[miguelgrinberg]

Implemented in #1288