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: > > On Fri, 2014-02-14 at 17:53 +0200, Luiz Augusto von Dentz wrote: > >> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > >> > >> This adds Suspend and Resume methods and 'suspended' value as status in > >> the Transfer interface documentation. > >> --- > >> doc/obex-api.txt | 18 ++++++++++++++++-- > >> 1 file changed, 16 insertions(+), 2 deletions(-) > >> > >> diff --git a/doc/obex-api.txt b/doc/obex-api.txt > >> index 1f22fea..0f57ce1 100644 > >> --- a/doc/obex-api.txt > >> +++ b/doc/obex-api.txt > >> @@ -90,12 +90,26 @@ Methods void Cancel() > >> org.bluez.obex.Error.InProgress > >> org.bluez.obex.Error.Failed > >> > >> + void Suspend() > >> + > >> + Suspend transference. > >> + > >> + Possible errors: org.bluez.obex.Error.NotAuthorized > >> + org.bluez.obex.Error.NotInProgress > >> + > >> + void Resume() > >> + > >> + Resume transference. > >> + > >> + Possible errors: org.bluez.obex.Error.NotAuthorized > >> + org.bluez.obex.Error.NotInProgress > > ^^^^^^^^^^^^^ > > > > Should this be a NotSuspended error? Or is it not an error to resume a > > transfer which is currently not suspended? > > Hmm, I would go for InProgress like in Cancel although now that you > mentioned we could perhaps ignore such errors if you don't see any > value on those. 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. Bye, Patrick -- 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
