Pieter, I recall you mentioning that there are three forms an industry can have as standard;
1) The best is a healthy number of implementations based on an open source specification;
2) The undesirable way is having a implemantations based on an API, namely JMS;
3) The lowest most undesirable way is having an implementation as industry standard, as this allows for vendor lockins, soaring prices, and tardy performance;
Having said that, ØMQ is an implementation (albeit fast and open) without an open specification , nevertheless, you are essentially basing your business on number 3. an implementation as industry standard (given that what you do, industry will follow). Secondly with your influential clout in this field, are you not pushing an implementation into the market as the next industry standard -> whereas it should ideally be an open spec?
Aside, what high performance (which excludes restms) substitute spec are you cooking up? Is there a slight possibility that you will reverse engineer the spec from ØMQ?
Nice question. 0MQ has a wire protocol but it's minimalist, just doing framing. As we push 0MQ out into wider use we'll grow the protocol stack upwards. It'll take years. We do have a protocol specification project - http://rfc.zeromq.org/
We do intend to deliver IETF-quality specs that turn messaging patterns like pubsub into 1st class citizens of the Internet, so that arbitrary vendors can produce pieces that plug into this. But these specs will still be really simple.
I've always advocated a standard API for AMQP and proposed one (WireAPI) years ago, because this reduces vendor capture. Imagine if vendors designed arbitrary socket APIs... well some do, and it locks their users in.
So 0MQ is partly an API standardization project, partly an architecture project (to build a layer that seems to be missing from the stack), and partly a protocol specification project.
I wish you strength and that the community support you! It looks like a decent direction to move in.
Your efforts at messaging pattern commodification on the Internet looks especially interesting, given your experience with restms. I hope this cracks it and makes life easy for all of us!
1) The best is a healthy number of implementations based on an open source specification;
2) The undesirable way is having a implemantations based on an API, namely JMS;
3) The lowest most undesirable way is having an implementation as industry standard, as this allows for vendor lockins, soaring prices, and tardy performance;
Having said that, ØMQ is an implementation (albeit fast and open) without an open specification , nevertheless, you are essentially basing your business on number 3. an implementation as industry standard (given that what you do, industry will follow). Secondly with your influential clout in this field, are you not pushing an implementation into the market as the next industry standard -> whereas it should ideally be an open spec?
Aside, what high performance (which excludes restms) substitute spec are you cooking up? Is there a slight possibility that you will reverse engineer the spec from ØMQ?