The scctl tool uses some functions like setReceiversFromSender() from libupnpp. Unfortunately, in case of an error the reason is not passed to the caller, but only printed as a debug message. As changing the function prototypes means breaking the API, so I would like to know about your opinion.
Discussion
-
medoc
2017-09-27I have added interfaces (e.g. setReceiversFromSenderWithStatus()) which do the same thing as the existing one, but returning status. This should be compatible on a binary and source level with older code. Please tell me if they work for you.
-
jk
2017-10-04I've tested the additional interfaces. Some comments:
1) In
setReceiversFromSenderWithStatus()the error reason fromgetSender()is not passed to the caller.
2) InsetReceiversFromReceiverWithStatus()the error reason formstate.state != ReceiverState::SCRS_PLAYINGis not passed to the caller.Of course, the functions are not used by scctl by default yet. The idea is that an external tool communications with scctl in server mode and gets a status if a command was successful or not. In case it was not, an error message shall be available.
-
medoc
2017-10-07The missing reasons should be fixed by the latest commit: in case the error reason is global and not related to a specific receiver, the function returns false and sets the reason in the first vector entry.
-
medoc
2017-10-14As you note, using this in scctl right now would break compatibility. Will do it one day. for now a possible approach is to check that the targets are in the desired state after running the scctl command.
-
jk
2017-10-17Sorry for the slow response time. The issue has very little priority right now, so no need to hurry :-)
-
medoc
2017-11-29- status: open --> closed
-
medoc
2017-11-29Not a libupnpp issue any more: the libupnpp part is fixed.