Re: [RFC 5/7] Deprecate virConnectNumOfDomains()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2018-10-03 at 13:14 +0200, Jiri Denemark wrote:
> On Tue, Oct 02, 2018 at 17:25:34 +0200, Andrea Bolognani wrote:
> > 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.

Yeah, I've run into the RPC issue and mention it in the cover letter
as something that needs to be addressed before this approach can be
realistically considered.

The idea of using events to report warnings sounds neat! I wonder
much of a limitation the fact that you'd need to have an event loop
running would be in practice...

How likely is it that someone will write/has written a useful,
non-helloworld libvirt application that doesn't have one? Could we
detect whether an even loop is running from library code and, much
further down the line, refuse to execute commands unless it is?

Of course then you get into the fun of warning developers that
they're not going to receive warnings :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux