On Tue, Oct 02, 2018 at 17:25:34 +0200, Andrea Bolognani wrote: > On Tue, 2018-10-02 at 16:43 +0200, Peter Krempa wrote: > > On Tue, Oct 02, 2018 at 16:14:44 +0200, Andrea Bolognani wrote: > [...] > > > @@ -97,6 +97,11 @@ virConnectNumOfDomains(virConnectPtr conn) > > > int ret = conn->driver->connectNumOfDomains(conn); > > > if (ret < 0) > > > goto error; > > > + > > > + virReportWarning(VIR_ERR_DEPRECATED_FEATURE, > > > + "%s", > > > + "virConnectNumOfDomains()"); > > > + virDispatchError(conn); > > > > I don't think our API contract allows for reporting an error AND > > returning success. And even if we didn't specify it it's pretty much > > assumed right now, so I'm not in support of this. > > I'm afraid I don't have a very good answer for this concern, as > for the most part I share it. > > This is the best I could come up with on my own; hopefully other > developers such as yourself will contribute to the discussion and > we'll collectively come up with something much better :) Technically you could introduce a new event and report warnings as events. That would much cleaner IMHO. Of course, apps would have to run an event loop and register for getting such events, but not doing so is not too different from just ignoring them when they are forcefully pushed on clients by some ugly black magic. Your approach only works for stuff that can be detected at a client library level, but useless in case you'd want to deprecate something in an XML, for example. Our RPC can only transfer a success or an error, but not both. A new event would be useful for all cases and you could even report several warning for a single API call. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
