From: Andrew Kohlsmith <akohlsmith-bluez@benshaw.com>
To: bluez-users@lists.sourceforge.net
Date: Thu, 10 May 2007 09:44:39 -0400
References: <4641DA61.8040709@tao-group.com>
	<200705100719.36399.akohlsmith-bluez@benshaw.com>
	<1178801877.25565.114.camel@aeonflux.holtmann.net>
In-Reply-To: <1178801877.25565.114.camel@aeonflux.holtmann.net>
MIME-Version: 1.0
Message-Id: <200705100944.39791.akohlsmith-bluez@benshaw.com>
Subject: Re: [Bluez-users] API documentation?
Reply-To: BlueZ users <bluez-users@lists.sourceforge.net>
Content-Type: text/plain; charset="us-ascii"
Sender: bluez-users-bounces@lists.sourceforge.net
Errors-To: bluez-users-bounces@lists.sourceforge.net

On Thursday 10 May 2007 8:57 am, Marcel Holtmann wrote:
> D-Bus is the solution for a generic IPC between applications or daemons
> and the size of the system doesn't matter. I never said that D-Bus is
> perfect, but it is time that all the embedded people that complain about
> D-Bus actually start fixing it. Believe it or not, D-Bus is the way to
> go for shrinking the memory footprint in your embedded systems, because
> all applications will use the same IPC.

I understand your reasons for using D-Bus; I really do.  It's a pain in the 
ass to try and maintain more than one IPC mechanism for any project, BlueZ or 
otherwise.  I honestly don't fault you at all for selecting D-Bus, and my 
aside from my recognition of it elegantly solving a particular problem for 
you, I also tend to think that if you're using bluetooth you've likely got 
enough memory for a full-blown message bus such as D-Bus as well.  
Complaining about the requirement for D-Bus for BlueZ is kind of like 
complaining about the need for the TCP part of the IP stack if all you're 
using is UDP and ICMP.

Having said that, I tend to complain about D-Bus because it's so goddamned 
convoluted, even for a regular desktop application.  I am chalking that up 
mostly to my own ignorance on the use of and architecture of the message bus.

I disagree, however, that it's the bees' knees when it comes to unifying IPC 
in all circumstances.  For many applications, both embedded and not, there is 
absolutely NO NEED for an abstraction layer this "thick" -- I don't give a 
rat's ass for introspection, data typing, nor any of the loftier goals that 
D-Bus addresses.  IOCTLs are more than enough for most of my applications, 
and the fact that they change from time to time... who cares?  Embedded 
systems don't evolve nor do they get updated anywhere NEAR as quickly as 
desktops.  When something changes it's because of a damn good reason, not 
because of "hey wow, there's a new version out!"  Besides that, I get by, as 
many others do, with FAR lighter IPC mechanisms, including passing pointers 
around to shared data structures.

As I review what I've written here, I find myself idly wondering about 
a "dbus-lite" -- a very thin emulation of the D-Bus API which strips away 
everything that makes D-Bus so cool and lets us smaller guys put this issue 
to rest once and for all.

-A.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users