[pedoh]

> Last I checked, it's being completely rewritten in a different programming language.

The rewrite you mention is, I believe, Crossroads I/O ( http://www.crossroads.io/ ). Martin Sustrik was one of the creators of ZeroMQ to begin with.

He's got a writeup as to why he should have used C to begin with ( http://www.250bpm.com/blog:4 ).

[rumcajz]

Hi, that's Martin Sustrik here. Couple of points:

1. As for lost requests, the right thing to do is to timeout the request and re-send the request if the response haven't been received. This should be done inside 0MQ/XS, however, it's pretty easy to do in the application so nobody so far felt incovenienced by it so much as to implement the feature.

2. As for the implementation language C would have been better than C++, but that's only an implementation detail and of not much interest to 0MQ/XS users.

3. Finally, yes, the 0MQ/XS functionality should be implemented in the kernel. Here's the Linux kernel implementation:

https://github.com/250bpm/linux/tree/sp-linux

Here are the userspace examples:

https://github.com/250bpm/sp-userland

Here's the discussion group:

https://groups.google.com/forum/?fromgroups#!forum/sp-in-lin...

However, the problem with kernel implemetnation is that it is -- obviously -- not multi-platform. Thus we'll need the user-space implementations in the future, at least for obscure operating systems.

[the_mitsuhiko]

> Hi, that's Martin Sustrik here. Couple of points:

Out of curiosity, was it impossible to prevent the fork from happening? I do like the idea of ZeroMQ quite a lot but this can only work if it will end up on kernel level at one point and if two projects compete for that spot that probably does not help its cause much.

[rumcajz]

The fork was over trademark policy, not any technical matter. So no, it was not possible to prevent it. To avoid trademark restrictions, it was necessary to change the name of the project.

Anyway, there's only one Linux kernel implementation and I am not aware of anyone trying to do the same (except the dubious attempt to get DBus into kernel).

Finally, the ultimate goal of the whole project is to make messaging integral part of the Internet stack. That means standardising the protocols in IETF. And having at least 3 independent implementations makes it almost suitable for fast-tracking.