On Sat, Jan 31, 2015 at 7:29 AM, Fraser Adams <fraser.ad...@blueyonder.co.uk
> Thanks for the heads up Rafi.
> I'll take a look when I've got a moment, that's not actually something
> I've noticed before.
> TBH I'm *pretty sure* that when I was developing this stuff I'd have done
> what you've done, so I'm a bit baffled but I've mostly been using non Debug
> builds lately and it's quite possible that some emscripten change has
> caused this - it's quite a dynamic project.
Yeah, I wondered about that too. I did upgrade from whatever version I
installed a few months ago to the latest as of a week or two ago, but it
didn't seem to make a difference.
> Hopefully you noticed my other mail on the ws WebSocket library change
> borking the bindings, sigh!
> Be aware that I'm currently in the process of changing the package name to
Thanks for the heads up.
FWIW, I'm not sure it necessarily makes sense ultimately to have separate
packages for the two of them. My plan to reconcile them is basically to
refactor messenger into a pure event handler that is a composed of a number
of smaller event handlers. This will allow you to use multiple messengers
inside a single reactor along with other more explicitly managed
connections, and also allow you to customize the behavior of messenger to a
much greater degree since you can control how it is assembled from its
component handlers and insert your own event handlers if you wish.
Ultimately I don't expect them to be alternative APIs, but rather for the
reactor to have a library of handlers to choose from that include messenger
as a simple entry point that lets you get up and running without having to
understand anything other than 'message' and 'address'.
Of course this is all just a plan at the moment, so a defensive name change
probably makes sense in order to allow us to break compatibility if
necessary. I just wanted to be clear that my plan is to avoid having two
alternative APIs in the end.