[ANN] adbus - initial release

[James McKaskill]

This is the initial release announcement of adbus.

Where to get:

Code - http://github.com/jmckaskill/adbus
Documentation - http://jmckaskill.github.com/adbus/

About:

adbus is a portable C library for both dbus clients and bus servers.
Most notably it does not layer on top of libdbus, but implements the
full stack.

Its main goals are:
- Portability - it's written in the common subset of ISO C and C++ and
uses only the CRT except for the optional adbus_Socket module which
uses the BSD socket API and some atomic operations found in
adbus/misc.h
- Ease of use - it's designed to be easy to use in a C app from the get go
- Size - this may not matter too much on desktop systems, but every
little bit counts on an embedded device
- Speed - ditto

Notably the library is designed for speed not security in that it has
very little up front argument checking. Thus its better positioned for
session, application specific, or embedded client/servers rather than
desktop system services.

Also included in the source distribution are bindings for:
 - C++ - This is a header only wrapper around the base c library
providing class wrappers, templated callbacks for member functions and
exceptions for errors.
 - Lua - This has full support for exporting interfaces, but at the
moment I'm really only using this for synchronous proxies for
scripting applications.
 - Qt - This is meant to be a drop in replacement for QtDBus, but it's
not quite finished.


Why I wrote this or is it just NIH gone mad:

In my day job, I work on machine control systems for construction
machinery. This involves a number of embedded devices all talking over
CAN, serial, etc to a main display running windows ce. For development
purposes, we have a number of simulation apps running on the desktop
written in a mixture of c, c++, c#, lua, and python. At the moment
this is a bit of a kludge fest. I thus started looking at using dbus
to consolidate the communication between all the various apps as well
as making them all scriptable. Thus simulated CAN, serial, etc comms
just become special named signals, and I can write a single lua or
python script that can start and setup all the various sim apps as
well as sitting around and logging what's going, actively running a
test script, etc.

Up to this point I was mostly happy using QtDBus (with a few kludges
to get around the lack of a decent variant), but the problem is that
we want to run a number of these simulator apps on the CE display
itself for demo/tradeshow purposes. Thus any solution I went with
needed to support windows CE (even worse, CE 4.2, which qt does not
support).

This gave me two options a) fix up libdbus for wince and work on top
of that (possibly using the dbus cpp bindings) or b) implement a
simple client manually. I ended up going for the latter as it fit in
with our build system much better and would result in much smaller
libraries.

The library then ballooned in scope a bit from there when I added the
server side. (The server stuff actually ended up being pretty
straight-forward as it really only involved doing the dispatch - the
bus service itself is done by having a loopback client connection
within side the server module.) However the library is still quite
small (the release dll on my windows box is about 100k).


Building:
At the moment I regularly build and use the library on linux/amd64 and
VS2005/x86. Platforms outside of that, I have no clue, but it should
build with minimal effort.

Linux

To build on linux I use tup (see http://gittup.org/tup/), which can be built by:
git clone git://gittup.org/tup.git
cd tup
./bootstrap.sh

Building adbus is then a matter of:
cd adbus
tup init
tup upd

Alternatively the C lib can be built in one command manually with:
gcc -shared -DADBUS_SHARED_LIBRARY -o adbus.so -Iinclude/c -fPIC
--std=gnu99 adbus/ *.c dmem/ *.c

Visual Studio
I have included solution and project files for VS2005.

Others
It should be a simple matter of just pulling in all of the C files and
building them into a library.


Todo:
adbus:
 - Finish off the multithreading and blocking support
 - Make adbus_conn_parse and friends reentrant from callbacks
 - Errors from the bus server for method calls should be accepted
(this involves changing the reply lookup to a hash table lookup for
reply serial plus checking the sender rather than two hash table
lookups as it is currently)
 - Write more tests

adbuscpp:
 - Document

adbuslua:
 - Document
 - Change blocking calls to use blocking support in base lib.
 - Play nicely with coroutines (possibly change callbacks to simply
copy message out and then wait until we get back to the main loop)

adbusqt:
 - Finish off (waiting on the blocking and reentrant support)

Contrbuting, Bugs, etc:
If you feel like helping out, the best way is by forking it on github
and then sending me a merge request.
For bugs please use the github issues: http://github.com/jmckaskill/adbus/issues

PS - as for the naming it stands for "a dbus" or "alternate dbus" or
whatever backronym you can chuck at it

James