|
|
|
|
|
by setori88
5920 days ago
|
|
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? |
|
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.