Comments for page "Optimising Subscriptions in nanomsg"

(no title)

Mon, 19 Jan 2015 03:06:18 +0000

I don't think "goodness" of code look is a function of programming language. There is nothing inherent in C++ that would make code look ugly. Lack of engineering and architectural skills as well as good taste will result in ugly code in any language.

(no title)

Thu, 27 Jun 2013 18:44:22 +0000

Yes. That's the plan. Pluggable filters were once implemented in Crossroads I/O and I would like to implement the same thing in nanomsg.

(no title)

Thu, 27 Jun 2013 16:13:08 +0000

Have you considered making subscriber matching algorithm pluggable? For example a matching algorithm with a small subset of regex could be implemented using finite automata.

(no title)

Sat, 23 Mar 2013 22:16:08 +0000

I've written two lengthy article about why I opted for C instead of C++, but in the end you are right: C code just looks better :)

(no title)

Sat, 23 Mar 2013 22:12:40 +0000

Good to know!

I was just browsing the source on github, and it usually strikes me that well-written C is such a joy to read compared to most C++ projects I encounter (another good one that's totally unrelated: BlendELF on github). Of course, clear directory structures and file naming always help. Good luck with nanomsg, it's very interesting and I hope to do some work with it once it matures a bit more (unfortunately don't have the time to help out developing it right now, maybe later!)

(no title)

Sat, 09 Mar 2013 16:50:59 +0000

Thanks for kind words!

The two projects will stay separate. The main reason is that they have incompatible licenses (LGPLv3 for ZeroMQ, MIT/X11 for nanomsg.

In theory nanomsg, thanks to its permissive license, could be merged into ZeroMQ, however, that would leave users with a need for permissive licensing locked out, so it's not going to happen.

(no title)

Sat, 09 Mar 2013 16:45:51 +0000

I love reading about this, I'm currently researching on a good way to build a pubsub system for command-and-control for a possibly very large network. I think ZeroMQ will be more than sufficient (even Redis will do, which I'm also looking into because it could work as both a db and a pubsub system). However that doesn't stop me from reading op on good or better ways to do it in my spare time!

You're writing style is very clear (and the pictures help a lot too). Is the work on nanomsg every going to be merged into zmq or will it forever be separate? Does it have other goals or…?

Thanks for the article,
Nicolas