Extend and improve infrastructure for KBUS messaging - Revision history

Tibs: Remove linebreaks which make list items hard to read

2011-01-31T22:45:33Z

Remove linebreaks which make list items hard to read

Wmat: Added body of kbus proposal page.

2011-01-31T20:15:28Z

Added body of kbus proposal page.

New page

Extend and improve infrastructure for KBUS messaging

; Summary: Extend and improve infrastructure for KBUS messaging

; Proposer: Tony Ibbs <tibs@tonyibbs.co.uk>

== 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 [http://kbus-messaging.org/ home page].
* The main repositories are in its [http://code.google.com/p/kbus/ Google code project]
* The initial development of KBUS was funded by [http://www.kynesim.co.uk Kynesim],
and the [http://kynesim.blogspot.com/ Kynesim blog] has announcements and occasional
posts about KBUS
* The main KBUS documentation can be read
[http://html.kbus.googlecode.com/hg/docs/html/index.html here]. An introductory
paper prepared for EuroPython2010 is
[http://presentations.kbus.googlecode.com/hg/talks/europython2010.html here in
HTML], or [http://presentations.kbus.googlecode.com/hg/talks/europython2010.pdf here
as PDF]. Other presentations and talks can be found in the
[http://code.google.com/p/kbus/source/checkout?repo=presentations presentations]
repository.
* I had a showcase table at the ELCE 2010 meeting in Cambridge, giving out this
[http://kbus.googlecode.com/files/kbus.pdf 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
support.

== Comments ==

[[Category:Project proposals 2011]]

@@ Line 72: / Line 72: @@
 * The KBUS [http://kbus-messaging.org/ home page].
 * The main repositories are in its [http://code.google.com/p/kbus/ Google code project]
-* The initial development of KBUS was funded by [http://www.kynesim.co.uk Kynesim],
+* The initial development of KBUS was funded by [http://www.kynesim.co.uk Kynesim], and the [http://kynesim.blogspot.com/ Kynesim blog] has announcements and occasional posts about KBUS
-and the [http://kynesim.blogspot.com/ Kynesim blog] has announcements and occasional
+* The main KBUS documentation can be read [http://html.kbus.googlecode.com/hg/docs/html/index.html here].  An introductory paper prepared for EuroPython2010 is [http://presentations.kbus.googlecode.com/hg/talks/europython2010.html here in HTML], or [http://presentations.kbus.googlecode.com/hg/talks/europython2010.pdf here as PDF].  Other presentations and talks can be found in the [http://code.google.com/p/kbus/source/checkout?repo=presentations presentations] repository.
-posts about KBUS
+* I had a showcase table at the ELCE 2010 meeting in Cambridge, giving out this [http://kbus.googlecode.com/files/kbus.pdf handout]. It has a summary on the front, and some C code on the back.
 * The main KBUS documentation can be read
 [http://html.kbus.googlecode.com/hg/docs/html/index.html here].  An introductory
 paper prepared for EuroPython2010 is
 [http://presentations.kbus.googlecode.com/hg/talks/europython2010.html here in
 HTML], or [http://presentations.kbus.googlecode.com/hg/talks/europython2010.pdf here
 as PDF].  Other presentations and talks can be found in the
 [http://code.google.com/p/kbus/source/checkout?repo=presentations presentations]
 repository.
 * I had a showcase table at the ELCE 2010 meeting in Cambridge, giving out this
 [http://kbus.googlecode.com/files/kbus.pdf handout]. It has a summary on the front,
 and some C code on the back.
 == Scope ==
@@ Line 91: / Line 80: @@
 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
+* '''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.
-decision made about the C++ library. This should include updating the KBUS
+* '''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.
-documentation.
+* '''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 Poky/OpenEmbedded recipes:''' For someone with experience of
+* '''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.
-Poky/OpenEmbedded, presumably a week, including testing and documentation. For
+* '''Show/document use with Binder in Android:''' Start with an allowance of 4 weeks, to produce some solid examples of real use.
-someone without such experience, somewhat longer.
+* '''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 DEB and RPM packages:''' I don't have enough experience to quote for
+* '''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.
-this, but time needs to be allowed for creation of packages for
+* '''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.
-Debian/Ubuntu/MeeGo/Fedora (presumably), possibly at several versions, with adequate
+* '''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.
 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.