hookio/webserver — pull request #9 by alexstrat (2012-01-24 22:23:44+00:00)
Title: [refactor] Use of connect middleware && browser-bridge even more minimal

Hi,

This pull request is divided in 2 parts :

### Connect middleware or custom server : c283458ea36c011a31dbfb0faab06a4c333347f9 > 99d573fc5e008c37524a3f4e0585fa15d49b797a

These commits aims to make possible to pass one's own instance of http-server (or what ever you want : express server for instance). The socket.io (in dnode) instance will be started on this.

```js
var server = require('http').createServer();

var webserver = new Webserver({
name: 'hook.io-webserver',
webserver: server
});

webserver.start();
server.listen(8080);

```

But, for that-works-out-of-the-box reasons and retro-compatibility, you can pass a `webroot` path and, if you want, a `basicAuth` object, to start a static file server.

**Note :** Static server and auth are powered by [connect](https://github.com/senchalabs/connect) middleware. @jesusabdullah did something similar (#6) using union and ecstatic. I don't know pros and cons, but if one really wants to use union and co, it can instantiate it and pass the instance in `webserver` option : it should work !

### Browser bridge even more minimal : 0cca725adf7e833dbed9e35cd54c994c4438529d and d3e58bd7debc4b6ace0916dc9bf474333b6a9607

I actually tried to do my own fix of the problem of serving multiple client (#2 and #8) in commit 1faf23b39a1ff40c0cf628d7f364150d6aa4602e, but I experienced some bad behavior like echoes and I felt that doing some plaster-fixes was not the solution.

Besides, when I first came across webserver, I thought that all the intelligence of hook.io was conserved in the browser-side JS and that the purpose of the webserver-hook was simply to proxy (from webscoket to TCP stream) what came from the browser to the main hook and vice-versa. But I discovered that was not exactly the case.

Maybe is that approach closer to the original idea than the actual implementation ?

Anyway, in these commits, I managed to adopt this approach by connecting each dnode-websocket-client to a dnode-tcp-stream connected to the main hook. The browser-side hook has more intelligence and behaves like an independent hook.

By chance, this works and solves, among other, the problem of multiple client. It's beside very convenient to deal with a real browser-hook rather than with a shim hook.

I think there is a lot to win by adopting this approach, but there are, for the moment, some cons :

- this could be a waste of tcp-sockets : each connected client triggers the opening of a new tcp-socket with the main hook. A further amelioration would be to multiplex it on a single tcp-socket, but the demultiplexing in webserver is the difficult part..

- I sometimes experience some unexpected error logs (`Error: Request for non-enumerable method: cullYours`) : i didn't investigate their origin. This is not so annoying since they are catched and seem not to disturb the system.

**Note for the end :** I probably should have divided this in 2 pull requests, let me know if it's annoying.

I'm open to discussion !!