BIND 10 #1145: MessagePack as a possible replacement of MSGQ?
BIND 10 Development
do-not-reply at isc.org
Fri Jul 15 11:54:30 UTC 2011
#1145: MessagePack as a possible replacement of MSGQ?
-------------------------------------+-------------------------------------
Reporter: jreed | Owner: UnAssigned
Type: task | Status: reviewing
Priority: | Milestone:
critical | Sprint-20110802
Component: | Resolution:
Unclassified | Sensitive: 0
Keywords: | Sub-Project: Core
Defect Severity: N/A | Estimated Difficulty: 0.0
Feature Depending on Ticket: | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => UnAssigned
* status: accepted => reviewing
Comment:
Hello
Short: I recommend not using this.
The msgpack itself looks like really cool thing. But it is
serialization/deserialization ‒ in short, we could replace JSON with it,
but we have trouble with transporting it, not encoding the data. So while
this might provide some more performance (for the cost of changing a lot
of things and having to translate configuration and so on), it is not the
solution we need here.
It has a msgpack-rpc, which is closer to what we need, but:
* The documentation only talks about calling remote functions, not about
any kind of notifications or broadcasts. We would still need to implement
the message hub for it.
* The RPC part of C++ is testing stage, python is alpha.
* There are not many developers (there are few, but each of them seems to
be focusing on one language binding, the core, C++ and python seems to be
developed by two people only).
* It doesn't say what platforms it runs on. It notes that it needs new
kernel and it does _not_ run on RHEL5/CentOS5 ‒ I don't think they tested
it on any kind of BSD or Solaris.
* It depends on some mpio library, which isn't in gentoo repositories
(which is quite an indicator of „nearly nobody uses it“). The last release
of this one is from 2004, which indicates it might be dead. I didn't
manage to compile it, it needs libusb (don't ask me why) and it isn't
satisfied with libusb-0.1.12 nor libusb-copat-0.1.3.
* No documentation for the RPC part. The serialization part is
documented, but there's not much to document anyway.
So, in short, this might be a good tool for developing website with
frontend and backend, which will run on a server farm, but not
distributed, but I think it would cause more trouble for us than solve.
--
Ticket URL: <http://bind10.isc.org/ticket/1145#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list