Direct Messaging and Various Points of Confusion

[Jeremy Martin]

First time post in this group, and a Hook.io noob, so pardon any taboos and snafus :)

I've been looking at Hook.io to be the messaging layer of distributed analytics engine that my company is working on.  One of the things our messaging layer needs is the ability to send "direct messages" between nodes (or, Hooks, in this case).  I've seen it suggested in IRC that Hook.io supports this, but it depends on "how the API is used" (that's the most detail I've found thus far).  Anyway, that's some context, and to avoid turning this into a rambling question that's difficult to answer, let me try to break it down into some more concrete questions:

1. Is direct messaging (i.e., data is sent directly from hook-a to hook-b without hook-c or hook-server ever seeing it) possible?
   
2. If so, how is direct messaging accomplished?
   
3. Probably unrelated, but I've seen a couple references to the '**' operator (i.e., something like hook.on('**::foo')). I've tried to experiment with this, but things went horribly wrong. An infinite loop ensued resulting in hooks emitting "hook-a::foo", and then "hook-a::foo::foo", and then "hook-a::foo::foo::foo", and so on. This behavior pretty well destroyed any and all theories I had regarding the "**" operators function :)
   

Thanks in advance for any input!

[Jeremy Martin]

Quick followup: jesusabdullah kindly explained number 3 (regarding "**" namespacing) in IRC, so mainly looking for any help around direct messaging at this point. Thanks again!

[Marak Squires]

You aren't sending messages necessarily to a target, as much as listening for messages which may come in.

If you don't have event listeners on a hook for an event, that event shouldn't ever get sent to that hook. There is some negotiation logic to make sure events aren't sent to hooks that aren't listening.

As for **, its the double wildcard operator. It will catch or emit all events or all events in a group, i.e. hook.on('**::foo') 

If you are listening for all events on hook without any event group, it will most likely go into a rebroadcasting loop since it's listening for the same events its broadcasting out. We should probably put in safe guards to prevent rebroadcasting loops by throw / fail gracefully instead of spamming.

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[Jeremy Martin]

Thanks for the reply - that's reassuring that events aren't simply filtered by the receiving hooks (the ones that don't care about the events, anyway).

So it sounds like what I want to be doing is listening and emitting to sufficiently unique namespaces and event names, rather than attempting to fill out some magical "send-to" header somewhere (bad analogy, but that's the idea anyway)?  I also assume this means that routing is being done by the current "server hook" as well, as opposed to some direct channel between the sending and receiving hooks?

Thanks again!

[Marak Squires]

Yes it's generally a hub and spoke model, but it can recover from hub failure if you use --autoheal option. 

[Jeremy Martin]

I've been playing around with that option - very cool :)

I think we have a couple use cases where the volume of data being shuttled around might make the "hub" a bit of a bottleneck, but I believe we have some workaround solutions we can use there.  Thanks for your answers and all your work on Hook.io, it's some spectacular software!