Proposal: Extend and improve infrastructure for KBUS messaging

Tony Ibbs <tibs@...>

Extend and improve infrastructure for KBUS messaging

; Summary: Extend and improve infrastructure for KBUS messaging

; Proposer: Tony Ibbs <tibs@...>

== Description ==

KBUS is a lightweight, simple to use, reliable kernel-mediated messaging system
for Linux. It was developed specifically for use on embedded systems. It can
be used via low-level file access (<code>open</code>, <code>read</code>,
<code>write</code>, <code>ioctl</code>), but also has a C library, and APIs
for Python, Java and C++. The unit-tests use the Python API. We have just
begun the process of submitting the KBUS kernel module to the Linux kernel.

I would like to propose the following:

'''Bring all APIs to a consistent level:''' At the moment, the different
language bindings are at different stages. The Java binding does not yet make
all KBUS functionality available. The C++ binding includes some ideas which
could usefully be incorporated elsewhere. The internal code of the Python API
could do with some review, as it is the oldest. Finally, the C++ binding does
not use exceptions or RTTI (to allow its use in constrained conditions) and it
may be worth providing a "traditional" C++ API (with full use of exceptions)
as well.

'''Provide Poky/OpenEmbedded recipes:''' The aim is to make it easier for
people to incorporate KBUS into their projects.

'''Provide DEB and RPM packages:''' If KBUS does get into the kernel, then
packaging the associated libraries for the most popular Linux distributions
would be very useful. If KBUS does not get into the kernel, packaging the
kernel module is more or less essential.

'''Provide a good set of examples:''' Specifically, examples of "how to do
common tasks". The <tt>kmsg</tt> example program is useful, but not
particularly realistic. We hope one of Kynesim's customers will be releasing
its KBUS-using code later in the year, but KBUS is only a small part of the
whole. Actual targetted "how-to" examples are needed.

'''Show/document use with Binder in Android:''' KBUS has been used within
Kynesim to communicate between the Java and Linux levels of Android, in
conjunction with Binder. This works rather well. Documentation and decent
example code needs to be made available.

'''Provide a Java Message Services API:''' At ELCE 2010 several people said it
would be useful to do this, and that it would make KBUS more accessible to
Java programmers.

'''Provide a good Limpet exemplar:''' KBUS deliberately isolates its buses
(the "goldfish bowl" metaphor). However, it is sometimes desirable for a
program to believe it is talking via KBUS whilst messages are actually being
proxied between devices (possibly between machines). KBUS terms such proxies
"Limpets". KBUS message headers provide extra fields to help with this, and
part of the C library provides helper functions. There are simplified C and
Python Limpet examples in the repositories, but they are not suitable for
deployment. Ideally, implementations for two of the APIs would be written (C
and Python would be simplest).

'''Design a Javascript API and provide some implementations:''' One of the
obvious uses for KBUS is communicating between a browser and other software.
It would be useful to define a "standard" Javascript API. Even more
useful would be implementations for some of the commoner Javascript engines.

'''Investigate use as a reliable low-level driver for DBUS:''' This was raised
as a suggestion at ELCE 2010. The potential should be investigated, and if
feasible, a tentative implementation should be attempted.

== Related work ==

* The KBUS [ home page].
* The main repositories are in its [ Google code project]
* The initial development of KBUS was funded by [ Kynesim], and the [ Kynesim blog] has announcements and occasional posts about KBUS
* The main KBUS documentation can be read [ here]. An introductory paper prepared for EuroPython2010 is [ here in HTML], or [ here as PDF]. Other presentations and talks can be found in the [ presentations] repository.
* I had a showcase table at the ELCE 2010 meeting in Cambridge, giving out this [ handout]. It has a summary on the front, and some C code on the back.

== Scope ==

Experience shows that I'm not particularly good at estimating, but here goes...

* '''Bring all APIs to a consistent level:''' 4-6 weeks work, depending on the decision made about the C++ library. This should include updating the KBUS documentation.
* '''Provide Poky/OpenEmbedded recipes:''' For someone with experience of Poky/OpenEmbedded, presumably a week, including testing and documentation. For someone without such experience, somewhat longer.
* '''Provide DEB and RPM packages:''' I don't have enough experience to quote for this, but time needs to be allowed for creation of packages for Debian/Ubuntu/MeeGo/Fedora (presumably), possibly at several versions, with adequate testing and provision of a PPA or equivalent, followed by submission upstream. Someone (presumably the candidate) should then provide an ongoing commitment to look after the packages.
* '''Provide a good set of examples:''' This is, by its nature, somewhat unbounded (so someone should monitor progress!), but I'd suggest an initial 2 weeks for deciding what would be useful, and then at least 2 weeks for coding and documentation.
* '''Show/document use with Binder in Android:''' Start with an allowance of 4 weeks, to produce some solid examples of real use.
* '''Provide a Java Message Services API:''' 2 weeks to produce a good estimate of feasability and actual requirement, to be followed by a sensible quote for the actual time needed to produce a good implementation.
* '''Provide a good Limpet exemplar:''' I would suggest an initial implementation in Python, followed by an equivalent using any of the other APIs. Allow 4 weeks for the first implementation, to include good testing and documentation, and 2-4 weeks for the second.
* '''Design a Javascript API and provide some implementations:''' 2 weeks to document a preferred API. Estimates for particular engines (and choice of which engines are desirable) to be done thereafter.
* '''Investigate use as a low-level driver for DBUS:''' 2-4 weeks for an initial investigation (depending if the candidate needs to learn how DBUS works), followed by further work if it is deemed a sensible approach.

== Contractor Candidates ==

The obvious candidate for much of this work would be myself (particularly for
the first item). Other employees of Kynesim (several of whom have also
contributed to or used KBUS) are also obvious candidates. However, if someone
else was chosen for some or all of the work, this would be a good thing in
spreading knowledge of KBUS, and I would be very happy to give any necessary

== Comments ==

[[Category:Project proposals 2011]]

Bill Traynor <wmat@...>

Extend and improve infrastructure for KBUS messaging

; Summary: Extend and improve infrastructure for KBUS messaging

; Proposer: Tony Ibbs <tibs@...>

Thanks for the proposal, I've added it to the wiki, here:

[[Category:Project proposals 2011]]

Celinux-dev mailing list