0MQ Support

[msassak]

I believe the long term goal for cucumber-ruby should be to use ZeroMQ to handle all of the communication between the executor and the backend(s), the formatters, reporters, what-have-you. It will require re-thinking the design of large-ish portions of cucumber-ruby, and will take some time to get right, so it's not the immediate priority, but it would enable all sorts of use cases we could only dream of until now.

ZeroMQ In Ruby

[mattwynne]

That looks like some sexy tech I'd like to get my hands on!

I've been thinking for a long while that the architecture needs to be a central core that just fires out events, with a bunch of things (support code, formatters, GUI) listening to it and maybe calling back if they have something interesting to say. So yeah I think that sounds like a nice goal, although I think it would be healthy to hide it behind an abstraction layer, wouldn't it?

[msassak]

Absolutely about the abstraction layer. The great part about ZeroMQ is that out of the box it supports patterns for the major types of communication we do within Cucumber. Off the top of my head, reporting/formatting would be pub/sub and execution request-reply, but I don't think we have to stop there. All this is to say that our abstractions will likely end up being super thin.

[aslakhellesoy]

I'm not sure I understand the motivation for ØMQ. Do you have any examples of what ØMQ can do for us? I'm a little skeptical because it sounds like it might complicate the stack.

[msassak]

tl;dr

cucumber-ruby is already developing two abstractions (request/response execution and pub/sub reporting) that I suspect can be mirrored pretty easily in 0MQ, and which will gain for us more-or-less transparent, cross-language and cross-platform network communication. I'm not dropping anything to work on it, but I think it merits serious consideration.

More

I thought of using 0MQ while thinking of possible ways to support the use cases of the wire protocol more generally and with less code. @mattwynne hit the nail on the head when he mentioned a central, event emitting core and bunches of listeners, and 0MQ would make that easy. So there's the reporting / listening side of things, which can be supported out of the box with its pub/sub socket types, but there is also the execution backend--the wire server, which use case I believe we can simplify greatly by using 0MQ and focusing on the wire packet definition itself rather than connection handling.

More generally, 0MQ makes networking code so easy to write that I think people who would never think of spinning up a bare TCP connection would use 0MQ to talk with Cucumber in all sorts of interesting ways: tying it into monitoring systems, continuous deployment processes, etc. That in turn would open up the Cucumber ecosystem even more.

P.S. Typing that "Ø" is a little easier on your keyboard, isn't it? :-D

[msassak]

This issue about the wire protocol is relevant: https://github.com/cucumber/cucumber/issues/154. I was particularly surprised to find out that someone is using the wire protocol in conjunction with in-browser testing to bypass captchas while creating users. That's exactly the type of scenario I was thinking of when I mentioned tying Cucumber into all sorts of other processes.

[mattwynne]

I had a thought about this. One of the weaknesses, IMO, in the current Cucumber design is the way that UI concerns (e.g. a reference to an IO) leak into the domain model. I think a prime candidate for this kind of decoupling would be between the UI and domain model, thereby allowing people to build other GUIs on top of Cucumber. I think concentrating on this angle, rather than the interface between the model and the support code, would yield more obvious benefits, and help keep the domain model clean.

[msassak]

I think you and I are thinking along many of the same lines. Whether we use ZeroMQ or not, I think we should work out some use cases for user input and user interaction. As I do my crab-walk towards formatter support in cucumber-ruby the question of how to handle user interaction has really come into focus. I'll make an issue for it with more details in a few.