Tonights hacking: DripDrop now supports routing

DripDrop now supports routing, a feature sorely needed for more complex apps. It was pretty easy to implement by using ruby's singleton class. Here's the entire implementation:

I've also written a full example showing how to use the new routing syntax.

A new minor point release of the gem will be out within the week, once I've been able to test the routing out a bit more to make sure I like the style.

DripDrop bump to 0.3.0: Subclassing,Filtering, Consistency, and Specs

Just released DripDrop v 0.3.0. The big new features in this release are message subclassing and pub/sub topic filtering, both courtesy of John W. Higgins (wishdev), who did a phenomenal job engineering these features cleanly. The other major change is a revamped argument order for xrep and http servers and clients. These are more consistent with the web socket interface (message as first arg) and really clean up the API.

Message subclassing is especially exciting because now you're able to send messages with much richer behavior. The javascript API doesn't yet support subclasses explicitly (they just come through as plain DD.Message objects), but support should be forthcoming in the next release.

On top of all this, we now have more spec coverage! I'll admit the test coverage hasn't been great, since it wasn't baked in, but we're adding it in as we go, and when I have time, I'm trying to fill it in as well. Questions? Comments? I'd love to hear them, either here, on github, or on twitter @andrewvc .

PS.

My plans for distributed workers in DripDrop are on hold till I feel the reactor code is well spec'd. Additionally, I think a rails routes style DSL for managing all your socket names in larger apps might be more important. Or maybe it's a terrible idea, it's not quite a fully formed idea yet.

-- Andrew

Cleaned up DripDrop Syntax

I finally found the time to make some important small changes to DripDrop. I cleaned up the syntax quite a bit using instance_eval. The main style differences are as follows:

I'm finally adding specs to it (Bad... I know). Writing specs for ZeroMQ isn't necessarily easy due to the fact that some sockets like pub/sub, while working fine in practice, don't exhibit the 'perfect' behavior your test framework wants. Shouldn't be too bad for the other socket types though.