From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [Bluez-devel] DBUS service support - Initial library From: Marcel Holtmann To: bluez-devel@lists.sourceforge.net In-Reply-To: References: <1115901694.18499.32.camel@pegasus> <1116844053.30044.59.camel@pegasus> Content-Type: text/plain Message-Id: <1116925644.30044.140.camel@pegasus> Mime-Version: 1.0 Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 24 May 2005 11:07:24 +0200 Hi Claudio, > Regarding our suggestion about the service name. I consider the > following basic features essential to establish and control connections: > * Search for a service (provided by sdptool) > * Display local devices (provided by hcitool) > * Switch master/slave role (provided by hcitool) > * Listen for PAN connections (provided by pand) > * Connect (provided by pand) > * Disconnect (provided by pand) > * Display active connections (provided by pand) > > According to D-BUS specification when messages are received over a > D-BUS connection, > they are sent to a specific object, not to the application as a whole. > Each object supports > one or more interfaces. > > We have two options: > 1. define one object with only one interface > eg: > object:org.bluez.pand > interface:org.bluez.pand > 2. define one object with multiple interfaces > eg: > object:org.bluez.pand > interface: org.bluez.pand > interface: org.bluez.sdp > interface: org.bluez.hci > > For the both cases, pand will be the daemon responsible for > provide this interfaces/services. > What approach do you preffer? > The last alternative is better because it is possible define more > detailed rules in the dbus configuration file. this might be, but until we don't fully understand what functionality we need to provide over D-Bus I like to go with 1). In general the first version of an API sucks and I don't wanna spread it over different interfaces and have to deprecate them. > Another point is the header for dbus services, the client application > must know the message format, therefore the header file(dbus_services.h) > will be required. In the future, develop a library hidding D-BUS message > details is a better option. Then make it dbus.h for the service definitions and move the rest into dbus.c and the function declaration into pand.h. For now copy the dbus.h to the client application and we will sort out the details of it later. Regards Marcel ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel