Re: Wizard patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, 2008-06-30 at 16:06 +0200, Marcel Holtmann wrote:
> > It also adds a new function: bluetooth_client_cancel_call().  This
> > cancels the last client call made for the given adapter/address.
> it only makes sense for the create bonding call, because the others
> can't really be canceled. So my proposal is to leave the others out of
> this change and implement create_bonding and cancel_bonding.

Except that one of my other patches adds a new cancelable function
_connect().  So we would need maybe specific cancel_bonding and
cancel_connect functions.

But why can't the others be canceled?  Just on the assumption that the
DBus communication will be so fast as to not really allow time for
canceling?  Or that by the time you send the message, it's all said and
done anyway?  I don't understand the nitty gritty details of dbus async

I figured that as a matter of principle, if you have an async API like
this, it ought to allow for canceling because the very nature of async
suggests a period of time in which your program is doing other things,
one of which could conceivably trigger a cancel.

But I agree it's largely a moot case for something like _remove_trust().
I just figured it would be cleaner to do the set of them.


Attachment: signature.asc
Description: This is a digitally signed message part

Check out the new Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Bluez-devel mailing list

[Index of Archives]     [Linux Bluetooth Devel]     [Linux USB Devel]     [Network Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux