BIND 10 #849: DBus as possible replacement of MSGQ.

[BIND 10 Development]

#849: DBus as possible replacement of MSGQ.
-------------------------------------+-------------------------------------
                 Reporter:  vorner   |                Owner:  vorner
                     Type:  task     |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:           |  Sprint-20110419
  Unclassified                       |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => vorner


Comment:

 I agree with Michal and have the following additional comments:

 '''Licence'''[[BR]]
 * Even with AFL "Some of the standalone binaries are under the GPL only"
 (from the source code's COPYING file).  This raises the bar but does not
 necessarily rule it out - after all, if these are standalone, then BIND 10
 will not be a "derivative work".
 * With AFL, we would need to prominently attribute in the source code that
 part of the code is D-Bus and subject to the AFL.
 * When AFL code is distributed, "You must make a reasonable effort under
 the circumstances to obtain the express assent of recipients to the terms
 of this License.".  Obviously the question of "what is reasonable" is
 subject to interpretation but if the code is downloadable from a web site,
 I would argue that "reasonable" would include the need to check a box to
 confirm that person downloading the software has read the terms and
 conditions before the download is allowed.

 However, as Michal noted, the FAQ explicitly states that it can be used in
 proprietary applications.

 '''Bindings'''[[BR]]
 Regarding the C++ bindings, D-Bus is written in C so it should not be an
 insurmountable problem to create a useful interface layer in C++.
 However, the documentation does warn "If you use this low-level API
 directly, you're signing up for some pain" which may indicate that coding
 our own binding in C++ will be far from straight forward.


 '''Miscellaneous'''[[BR]]
  * Sending file descriptors for sockets between processes in Windows is
 awkward but can apparently be done through the function
 WSADuplicateSocket; whether D-Bus can handle this is another matter.

  * D-Bus comes with qdbus, a tool to examine the state of the bus and
 generally aid diagnosis of problems.  This could prove very useful and
 avoid us having to write our own.

  * I'd see the real blocker in the use of D-Bus as being how important
 cross-machine communication is.  TCP support appears to be very limited -
 two quotes from the D-Bus web pages are:
    - "Currently the communicating applications are on one computer, or
 through unencrypted TCP/IP suitable for use behind a firewall with shared
 NFS home directories."
    - "The TCP/IP transport isn't tested in use and it has the problems of
 access control, lack of encryption, and inability to go through firewalls
 and NAT."

 '''Comments on Conclusions'''[[BR]]
 I think this seems a good product, although I have the following
 reservations:
 * Licence: the fact that part of the distribution - even if only stand-
 alone applications - is GPL.  Introducing that caveat into BIND 10
 documentation may make people nervous.
 * The need to write our own C++ wrapper.  This may be non-trivial.
 However, if we do this we should consider making it a separate project and
 making the output available to the D-Bus community.
 * If cross-machine support is required, the limited TCP support may be an
 insuperable hurdle.

 For these reasons, I'd be keen to see if something else is better before
 making a decision to go with this one.

-- 
Ticket URL: <http://bind10.isc.org/ticket/849#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development