3 ms·

ZeroRPC is pretty cool but it's a different concept. It uses 0MQ sockets as the transport whereas we use RabbitMQ. This allows us to do zero-configuration servi

ZeroRPC is pretty cool but it's a different concept. It uses 0MQ sockets as the transport whereas we use RabbitMQ. This allows us to do zero-configuration service discovery and complex routing. Bridge allows you to securely expose APIs to "untrusted" clients such as browsers and mobile clients. ZeroRPC does not do this because 0MQ doesn't allow such access control.

kbd 14y ago
Neat, thanks for your response. Question for you: on your roadmap[1] you write: > Efficient binary data transfer > This would allow for some interesting applications such as video streaming, file transfer, image processing and more. Binary data support was one of the key reasons Github chose to roll its own serialization format (BERT) instead of using existing options. Why is BERT > MessagePack for this? [1] https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap
- sthatipamala 14y ago
  To clarify, Bridge's binary serialization will be MessagePack. Github's BERT is also good for binary serialization but we decided to go with MessagePack because of its wide language support. I don't think BERT-RPC is necessarily _better_ for binary. But we referenced it in the roadmap as a good idea that we derived inspiration from.
shykes 14y ago
sthatipamala is correct. A few more points on the differences between ZeroRPC and Bridge: * ZeroRPC has been open-sourced by dotCloud with no plans for monetization. It's just a fundamental piece of infrastructure which we think is worth sharing. Licensing fundamental infrastructure software is not our business (also: it's very hard). * I see very interesting scenarios where ZeroRPC can be integrated with Bridge. There is already work on integrating it with systems very similar to Bridge, for example Stack.io (http://github.com/dotcloud/stack.io http://github.com/dotcloud/stack.io).
- shykes 14y ago
  Actually come to think of it, this is more similar to dotCloudJS by the dotCloud labs team: http://js.dotcloud.com http://js.dotcloud.com
- m0th87 14y ago
  Few more points: * Bridge currently uses a central broker, ZeroRPC is broker-less. * ZeroRPC gives you streaming responses (similar to python generators). Bridge instead provides pub/sub. * Bridge uses callbacks everywhere, whereas it varies for ZeroRPC based on language implementation. Our node.js version obviously uses callbacks, but the python version doesn't, thanks to gevent.
  - vitus 14y ago
    I can't imagine that WebSockets would be used outside of communicating with the browser -- in fact, a quick glance at the Python client library seems to indicate the use of raw TCP sockets.
    - m0th87 14y ago
      Apologies, must've misread something. Removed that point.

kbd 14y ago

Neat, thanks for your response. Question for you: on your roadmap[1] you write: > Efficient binary data transfer > This would allow for some interesting applications such as video streaming, file transfer, image processing and more. Binary data support was one of the key reasons Github chose to roll its own serialization format (BERT) instead of using existing options. Why is BERT > MessagePack for this? [1] https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap

sthatipamala 14y ago
To clarify, Bridge's binary serialization will be MessagePack. Github's BERT is also good for binary serialization but we decided to go with MessagePack because of its wide language support. I don't think BERT-RPC is necessarily _better_ for binary. But we referenced it in the roadmap as a good idea that we derived inspiration from.

shykes 14y ago

sthatipamala is correct. A few more points on the differences between ZeroRPC and Bridge: * ZeroRPC has been open-sourced by dotCloud with no plans for monetization. It's just a fundamental piece of infrastructure which we think is worth sharing. Licensing fundamental infrastructure software is not our business (also: it's very hard). * I see very interesting scenarios where ZeroRPC can be integrated with Bridge. There is already work on integrating it with systems very similar to Bridge, for example Stack.io (http://github.com/dotcloud/stack.io http://github.com/dotcloud/stack.io).

shykes 14y ago
Actually come to think of it, this is more similar to dotCloudJS by the dotCloud labs team: http://js.dotcloud.com http://js.dotcloud.com
m0th87 14y ago
Few more points: * Bridge currently uses a central broker, ZeroRPC is broker-less. * ZeroRPC gives you streaming responses (similar to python generators). Bridge instead provides pub/sub. * Bridge uses callbacks everywhere, whereas it varies for ZeroRPC based on language implementation. Our node.js version obviously uses callbacks, but the python version doesn't, thanks to gevent.
- vitus 14y ago
  I can't imagine that WebSockets would be used outside of communicating with the browser -- in fact, a quick glance at the Python client library seems to indicate the use of raw TCP sockets.
  - m0th87 14y ago
    Apologies, must've misread something. Removed that point.