Hi Michael, > > > It also adds a new function: bluetooth_client_cancel_call(). This > > > cancels the last client call made for the given adapter/address. > [snip] > > 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. sounds good to me. The bonding case is special since it can only do one at a time. > 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 > communication. > > 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. It will give you no advantage whatsoever. So not worth it. Regards Marcel ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Bluez-devel mailing list Bluez-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/bluez-devel
