Skip to content

Conversation

@davidbau
Copy link

This pull requests adds dynamic namespace support, virtual host support, and an optional /socket.io/status page to help monitor dynamic (and regular) namespaces.

It addresses #1854

From the library user's point of view, it doesn't change any existing behavior. Passes current unit tests, but adds some functionality.

Three new options.

host: true - enables hostname qualification on namespaces
host: 'roothost.com' - enables hostnames, but matching hosts (may be a regexp) are still unqualified
host: '*' - the default - all hosts are unqualified

retirement: 10000 (default) - the number of ms to wait before cleaning up an empty dynamic namespace

serveStatus: false (default) - set to true to enable socket.io/status

One main new public API

server.setupNamespace(pattern, fn) - call to set up all namespaces matching "pattern" (which may be a string or regexp).

The rules are: each namespace instance is called with at most one setup function. When a new dynamic namespace is connected by a client, the best-matching setup function is found and called. Exact string matches are preferred over regexps, and within those groups, the last registered name/pattern gets precedence. If no pattern matches a client's requested namespace name, an error is sent to the client.

Other public functions

server.getHost(conn) - override to normalize hostnames
namespace.host - has the hostname
namespace.fullname() - '//host/name'
namespace.retriement - set to milliseconds to persist after going empty (defaulted)
namespace.expire(fn) - register an expiration callback for when a stale namespace is deleted

@peteruithoven
Copy link

I really like the idea of dynamic namespaces, it could actually improve a application I'm working on.

@rauchg
Copy link
Contributor

rauchg commented Nov 23, 2014

I would like to add this, but it seems to me that this might be better done in userland, through middleware.

@davidbau
Copy link
Author

Agree in principle, but I couldn't find a clean way myself. Feels like you
would end up replicating a lot of what socket.io does. Any thoughts or
pointers?

I needed this in production, so I ended up resorting to an invasive
subclass https://github.com/PencilCode/dynamic.io.

David

On Sun, Nov 23, 2014 at 1:47 PM, Guillermo Rauch [email protected]
wrote:

I would like to add this, but it seems to me that this might be better
done in userland, through middleware.


Reply to this email directly or view it on GitHub
#1865 (comment).

@rauchg
Copy link
Contributor

rauchg commented Nov 24, 2014

I'm down for adding hooks to make it clean to do in user-land. For example, a place where a custom function can be called for matching an incoming connection to a namespace with the actual namespace object.

If a connection comes to /test/123, your function is called to verify that the namespace exists, and if so, it returns it. And it could be because the user registered /test/:uid for that case.

@csulok
Copy link

csulok commented Nov 24, 2014

Then it sounds an awful lot like standard connect middleware, where you can filter requests and pass requests to the next middleware with next(). It might be worth checking if it's possible to move the socketio connection listener to middleware.

app.get("/namespaces/:uid", function(req, res, next) {
    //verify namespace
    //initiate connection
});

@rauchg
Copy link
Contributor

rauchg commented Nov 24, 2014

That'd be nice, the problem being that it wouldn't work for WebSocket

@rauchg
Copy link
Contributor

rauchg commented Nov 24, 2014

And there's no req vs res duality in WebSocket, nor headers, etc.

@defunctzombie
Copy link
Contributor

Not a fan of this right now. I think it introduces a bit too much magic and custom response pages. I am not against this idea in general, but I somehow feel that regex or dynamic namespaces could be supported in a simpler manner.

Closing since @rauchg mentioned it would be better suited with hooks or similar for now. I don't want to leave it open to get stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants