Hi Patrick, On Thu, Feb 20, 2014 at 12:52 PM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote: > On Wed, 2014-02-19 at 19:11 +0200, Luiz Augusto von Dentz wrote: >> Hi Patrick, >> >> On Tue, Feb 18, 2014 at 6:54 PM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote: >> > On Tue, 2014-02-18 at 11:30 +0200, Luiz Augusto von Dentz wrote: >> >> Hi Patrick, >> >> >> >> On Tue, Feb 18, 2014 at 11:09 AM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote: >> > I think I would prefer to *not* get errors when Suspend() is called on >> > an already suspended transfer or when Resume() is called on a running >> > transfer. The rationale is that the caller will typically only care >> > about the end result and not so much whether it was the one who >> > triggered the change. If we remove NotInProgress resp. InProgress errors >> > from the API, then such a caller can treat all errors as fatal problem, >> > without having to check the exact error. >> >> Actually the NotInProgress error is for transfer queued, I guess for >> this case it makes sense to return an error since otherwise we would >> have to queue commands to be send when the transfer becomes active I >> believe this should probably be considered an error. > > Agreed, if suspending can't be done, then an error needs to be returned. > > It would be good to add information about the error to the > documentation, so that apps get at least some hint what they are > supposed to do in case of such an error (like aborting the queued > transfer (most likely) or waiting for it to start before suspending it > (seems a bit odd, but perhaps it is useful sometimes)). I went ahead and pushed with a note about NotInProgress error, if we figure that is not enough we can reword it to be more clear, but at least in terms of API and functionality it should be fine. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
