add wildcard support in emitter

[sintaxi]

could be nice if EventEmitter2 syntax was supported on events

sock.on('*', function(data){
  console.log('yay wildcard', data);
});

[gjohnson]

Just curious, what's the use case of having that? I have never used Emitter2... Just for debugging?

[sintaxi]

It's so you can trigger events on more broad or narrow event descriptions. Eg:

sock.on('basketball.nba.bulls', function(data){
  // do this only for the bulls events
});

sock.on('basketball.nba.*', function(data){
  // do this for all nba events
});

sock.on('basketball.ncaa.*', function(data){
  // do this for all ncaa events
});

sock.on('basketball.*.*', function(data){
  // do this for all basketball events
});

sock.on('*.*.*', function(data){
  // log everything ...
});

[gjohnson]

Gotcha, I will let @visionmedia decide on that. I could see some use cases where it could be beneficial (e.g a monitor system that emits alert types that you could pattern match on the other end, etc). Though I would opt for wrapping up a long over due release with all the new stuff we have in master first. The original project that pushed me to help on this project in the first place is coming back up, so I will finally have the time to head that up again...

[tj]

need to think on this haha, not against it. The one thing I don't like about their pattern matching is that * in my mind at least should match anything vs having to know the event segments. Maybe as a compromise we could support * only which would just punt the event name as an argument that you could match on. That's not as attractive though... hmm

[sintaxi]

Yeah totally. I bring it up because it looks like hook.io is EOL and it gave you this. Not to turn axon into hook.io but it may be able to address some of the use cases. Not sure what the performance penalty of using EventEmitter2 is. perhaps having the choice of emitter or emitter2 may be worth considering.

[sintaxi]

@visionmedia FWIW I agree regarding * and the event segment. May be a lot of work to do differently though.

[tj]

arguably that sort of thing could be part of the object(s) passed as well, sock.on('basketball', function(data){ data.league }) etc

[gjohnson]

Just to clarify, I would argue that the emitter socket should remain as is, and follow the same feel as the node-core emitter. I would only see this being part of pub/sub through topics:

sock.subscribe('foo*'); // maybe even regexp
sock.on('message', function(msg){});

[tj]

EmitterSocket is definitely a higher level one, we could possibly just produce regexps for the .on() calls filter on "message", but then we lose the possibility of doing selective reception later on unless we do translate those to .subscribe()s

[tj]

this would help for having some stable relay nodes that would relay everything, I'm a little torn since in general you can just use multiple sockets for multiple "topics" but I can see how that would become less true with some scenarios. I'll try out some simple str -> regexp conversions and see what the impact is like and / or EE2. I'm not sure I'm sold on how EE2 handles separators though

[sintaxi]

Thanks for the update. Let me know if there is anything I can do to help. I've been digging this library.

btw - I'm liking the glob-style pattern matching that redis gives you

[tj]

at very least we could add it as some sort of thing you opt-into if there ends up being a perf penalty worth caring about

[tj]

non-scientific benchmarks:

even our multipart support drastically reduces throughput, so the overhead of regexp-based subscriptions relative to that one is actually pretty low. I'm sure we could improve multipart, my guess is .concat() is probably not great, maybe some other things too

BEFORE:

    min: 244 ops/s
   mean: 145032 ops/s
 median: 20852 ops/s
  total: 109511 ops in 3.349s
through: 141.6328125 mb/s

    min: 3031 ops/s
   mean: 150450 ops/s
 median: 21432 ops/s
  total: 114290 ops in 2.592s
through: 146.923828125 mb/s

BEFORE (multipart):

    min: 244 ops/s
   mean: 80274 ops/s
 median: 150689 ops/s
  total: 94281 ops in 5.302s
through: 78.392578125 mb/s

AFTER (no subscriptions):

    min: 322 ops/s
   mean: 138694 ops/s
 median: 20565 ops/s
  total: 150902 ops in 4.105s
through: 135.443359375 mb/s

    min: 861 ops/s
   mean: 151069 ops/s
 median: 21248 ops/s
  total: 312569 ops in 9.340s
through: 147.5283203125 mb/s

AFTER (1 subscription):

    min: 389 ops/s
   mean: 70102 ops/s
 median: 15393 ops/s
  total: 98439 ops in 5.148s
through: 68.458984375 mb/s

AFTER (5 subscriptions):

    min: 325 ops/s
   mean: 67374 ops/s
 median: 14977 ops/s
  total: 137652 ops in 7.403s
through: 65.794921875 mb/s

[tj]

ah yup http://jsperf.com/concat-push/6

[sintaxi]

wow.

[tj]

hmm removing that only gave me about ~10% increase, I'll profile later and see what's up

[tj]

https://github.com/visionmedia/axon/pull/new/add/emitter-wildcards