Re: [Bluez-devel] D-Bus interfaces

[Marcel Holtmann <marcel@holtmann.org>]

Hi Fredrik,

> > >    3. Permanently configure device status (up/down).
> > Agreed. Put "reset" to this list.
> 
> Uhu? Permanent reset? ;)
> 
> > Maybe a flag for auto-up on/off per device would be nice.
> 
> What do you mean?
> 
> The intention was that when a device is permanently configured "down",
> it will be kept down regardless of reboots etc. It will only go up after
> using the other option, configuring it permanently "up". Then it will be
> kept up by hcid, after reboot etc. This is equivalent with having the
> "autoinit" option available per device, i.e. in the "device" parameter
> section.

I tought you meant up/down as real actions.

> > I don't think that we need that. The pairing mode from hcid can go away
> > and we should use multi every time.
> 
> I agree with the once/multi thing. But isn't it useful to be able to
> disable/enable pairing, i.e. deny/accept all pairing requests?

Why? If you want to deny a paring, you can click cancel on the PIN
request. And of course you can mark your device as non-inquiryable and
non-pageable.

Remember these are client options. If we come to the service options we
can think about once/multi/deny thing againg, but for the client it
makes no sense.

> > >    7. List permanently stored configurations.
> > >    8. Remove permanently stored configurations.
> > What do you mean by permanently stored configurations?
> 
> I mean what you asked above: Make it possible to list and configure
> previous attached devices. :) A "permanent configuration" is equivalent
> to having a configuration like "device 00:00:00:00:00:00 { ... }" in
> hcid.conf. (I know you want to have this in another database, but it
> would still be "equivalent" with this.)

So lets combine these with (1) and (2). How to present it, is a problem
of the UI.

> > >   12. Perform av device scan (this will also update the name cache).
> > We need something, but I am not sure how to do this. Let's put it at the
> > bottom of the list.
> 
> Something is needed when a user wants to request a pairing procedure
> through DBus. I suspect the user would like to select a device to pair
> with first, i.e. do a scan.

The pairing procedure should be run automaticly on the fist connect, so
we shouldn't care about it.

> > The pairing procedure should work in background and if a PIN is needed a
> > PIN helper window should be opened. Maybe you should look at the
> > bluez-pin program on the internet and the D-Bus extensions for hcid.
> 
> What do you mean? I suppose an application DBus callback would be needed
> to handle PIN requests.

Yes. Please look at the code that RedHat already ships.

> > The one-time PIN method is what I really want to have. So an application
> > can provide a previous entered PIN and send it to hcid. The hcid will
> > use this for the next PIN request (and don't call a PIN helper) and then
> > forget the PIN.
> 
> This sounds a bit strange. Isn't the PIN an on-demand thing? I mean, the
> user expects to enter the PIN which will be used for the current pairing
> procedure?

It sounds somekind weird, but it will help in some cases.

Regards

Marcel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel