Why is there a difference between server and client hook prefixes?

[noazark]

The whole idea behind hook.io is fault tolerant, distributed hooks. So why is there a convention change between events from a client hook and it's server? The server doesn't prefix the event with it's name, unlike all of the others. This means that you have to listen for two different events, one coming from a server and one coming from a client.

I've written a simple demonstration of this at https://gist.github.com/2393162. The idea is that you should be able to start up the two hooks and they will start communicating in both directions. However, to do this I have to listen for both:

self.on('b::hello', ...);
self.on('*::b::hello', ...);

The problem here is obviously that this is unmanageable for large enough applications. The only option around this seems to be a designated server hook, but what if it goes down? When the root goes down the next hook inline takes it's place, so should all hooks be considered server candidates?

A hooks name can be found by the third parameter passed into the handler, so why would it also need to be prefixed to the event name?

I feel like I am missing something huge here, so please enlighten me if you can!

[Erik Rothwell]

Yeah, it seems to me that event names should either always or never be
prefixed by the originating hook's name.

I find it's very useful to have the originating hook's name prefixed,
so that it's easy to listen on events from specific hooks. Except, you
can't do that with the hook that's the server because it doesn't
prefix its name.

And then, as you illustrate, if you have an event that's emitted by
both server and client hooks, you have to listen on two events in
order to handle what may be, conceptually, one type of event.

It may be better not to prefix at all and leave the event namespace
entirely up to the user, but either way it should be consistent, I
think.

Erik.

[Marak Squires]

Pretty sure this is a problem that needs to be fixed.

Been brought up before: https://github.com/hookio/hook.io/issues/157

Appending the server name was most likely done as a stop-gap in earlier versions of hook.io.

There is a gap in the API right now for listening to events by hook type and hook name. You should be able to easily listen to all events for a specific hook name, or from a specific type of hook. I'm not sure what this should look like.

I will take patches to fix this. 

Also, FYI, you may be able to get by this for now by using the ** operator like, self.on('**::hello')

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[noazark]

I must have glazed over the #157, thanks for the answer. '**::hello' does the job just fine for now.

[Marak Squires]

** is really a stop-gap for this problem.

Would appreciate any help in improving the internals of the hook.io's name / type system.