From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Johan Hedberg To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] [PATCH] dbus.c: cleanup/fix method parameter getting Message-ID: <20051107215732.GA19351@localhost.localdomain> References: <20051105124837.GA27883@localhost.localdomain> <1131315924.5824.14.camel@blade> <20051107093436.GB6845@localhost.localdomain> <1131359661.5824.97.camel@blade> <20051107121354.GA9950@localhost.localdomain> <1131368088.5824.116.camel@blade> <20051107145430.GA12669@localhost.localdomain> <1131397067.5824.145.camel@blade> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1131397067.5824.145.camel@blade> 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: Mon, 7 Nov 2005 23:57:32 +0200 Hi Marcel, On Mon, Nov 07, 2005, Marcel Holtmann wrote: > > > Every time that a client establish a connection with the d-bus daemon > > > the connection id changes. Therefore control client id is useful only > > > for clients that is always connected with the daemon. > > > > True, and that was also one thing I was worried about when it comes to > > the practicality of that solution (the settings wouldn't be persistent > > enough). So, I think using the user id might be better in this respect. > > I don't think so, because this options might be used not very often and > so having them per unix user doesn't help. Two different applications > running as them same user might have different needs. One wants to do > inquiry with another IAC, the other with the general IAC. This tends to > be a race condition. Ok, I see your point. I didn't quite understand the use-case you were thinking of earlier. One extra requirement that the dbus-id settings has is that we will have to monitor the lifetime of a D-BUS client (by listening NameOwnerChanged D-BUS signals) and remove the corresponding entry from the settings table when an id gets removed from the bus. > > However, let me now introduce a third option which we just discussed on > > IRC with Claudio: optional D-BUS method parameters. It would be quite > > easy to implement the methods so that the client could leave out most > > parameters in which case hcid (or bluetoothd) would use some set of > > default values. You could e.g. call the Inquiry method without any > > parameters and it would just work (kind of the same way that dbus-test > > allows doing "./dbus-test Inquiry" in which case it uses length=10 & > > num_resp=100 as the default values). If the client insists on using its > > own values for the method it would simply include them in the method > > call. > > Let's do this proposal first. Ok, I'll begin by doing a patch for Inquiry and PeriodicInquiry (probably during tomorrow). Johan ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel