Support for registering services dynamically

[marshallswain]

This is Dynamic Services on top of the recent 1.0.2 patch. I've also made it no longer a requirement to pass a callback (#96). If the request fails, it logs a message to the console for a developer to track down.

As for consolidating the code a bit more. This is basically creating a second path in the code to setup a service. The first way is through the setup methods, and now this for sure works after the server has started. I'm not sure if it would be possible to just use this new way BEFORE the server starts. I would have to check to see if there is anything that the setup methods put in place that the services require as prerequisites.

Update: We for sure have to wait until the providers are set in place, which isn't really guaranteed until after the server starts (since providers are setup with configure). There may be other optimizations that can be made?

Closes #67 and closes #82

[marshallswain]

For some reason I CAN create a branch on the main Feathers repo, but I'm not able to push to it, so there's a straggling branch called dynamic-services-2 hanging out right now. Update: Never mind, I wasn't able to push it, so there's no straggling branch after all.

[daffl]

I just double checked and you should have push access to this repository. Did you use git@github.com:feathersjs/feathers.git?

[marshallswain]

Ahh. I enabled two-factor auth. I forgot to use the personal access token. I pushed the branch.

[marshallswain]

I think it looks good besides that but maybe we can discuss if there is a way to consolidate functionality even more.

@daffl What did you have in mind?

[daffl]

Can we put this into a separate PR since it belongs to some different functionality?

[daffl]

Well it looks that for example the code from https://github.com/feathersjs/feathers/pull/107/files#diff-a89e33317f0c782705345838f29cf003R57 and https://github.com/feathersjs/feathers/pull/107/files#diff-dbb6eace96490fa4b721a67e6fd9340dR57 can be maybe consolidated into https://github.com/feathersjs/feathers/blob/master/lib/providers/socket/commons.js.

I'm also wondering if we could somehow hook into app.service and make sure that the provider methods can be called at any time? I think you a currently doing this in .use (at https://github.com/feathersjs/feathers/pull/107/files#diff-5372f626ee15242f1e2c6eb31655b4faR73) right?

[marshallswain]

OK. I moved most of it into the commons. You'll notice that in the this.info part of each provider I put an attribute called connections, which is used in commons.js here. I put it in this.info because I didn't want to pollute the app's global space. hmm... Actually, the way it is set up, this.info gets mixed into the app, now. That makes it so that Socket.io can't be used at the same time as Primus. That's not really a concern, is it? It seems like you'd be using one or the other.

I left the setupMethodHandlers() method in each one since the methodHandlers depend on the connected socket and use different parameter names. It can be done, but it felt a little hacky moving it into commons.js.

[marshallswain]

Oh. I also took that other commit regarding socket callbacks out.

[marshallswain]

I'll make a PR for it after we get this one merged.

[daffl]

Sweet! I will check it out tonight and then merge it in. This will make for a great 1.1 release. Debating if ZeroRPC support would be something worth considering for that, too (and writing up how use this as microservices).

Oh and I'd like to polish the website a little, too.

[daffl]

Merged! Great job!