Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign

[Marcel Holtmann <marcel@holtmann.org>]

Hi Claudio,

> 1. The functions get_device_name(hcitool.c) and
> get_peer_name(dbus-device.c) does the same thing. We should move it to
> a common file.

not right now. The code duplication is that small that I have no
problems with it and creating another internal library for it, is way
too much overhead.

> 2. The header file dbus.h intends to be a file used by D-Bus client
> developers. There are some constants, type definition and function
> prototypes that we could move to internal header file:
> "dbus-internal.h" or split into separeted file(one for each .c file -
> according with Johan's suggestion).

I have no favor in any direction at the moment, but I don't think that
we need a global dbus.h file for other C clients using the D-Bus
interface. My understanding is that no client should depend on any code
or headers provided by bluez-libs or bluez-utils. We will make a clean
split with the D-Bus API. If this means that every client has some kind
of duplication, so will be it.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel