On Fri, Nov 14, 2008 at 07:28:09AM -0500, Ben Guthro wrote: > To revisit the DEFINED, UNDEFINED topic - I have been giving this some thought, > and it seems like it is redundant information to me. > > Doesn't the existence of a config file define the difference between a transient > and a persistent domain? > Therefore this could be tracked solely with the enum values we have? > If a transient domain becomes persistent via adding a config file, the ADDED > event would be emitted, denoting a config file came into being, and by definition > changing this domain from transient, to persistent. > I'm not sure I understand the need for these events. I see what you mean - if you have tracked a VM through its entire lifecycle you can actually determine whether it was persistent or transient. The missing piece is when you populate your initial list of domains at startup, by calling virConnectListDomainIDs, you don't know which of those initial set of domains is persistent. We can better solve that though by providing an explict API call virDomainIsPersistent(virDomainPtr); So, yes the extra events I suggested for this are redundant. > Moving on to the shutdown reason discussion - > I can certainly see the need to know why a domain stopped. > That said - would it not be more consistent with the API to introduce an > event "sub-type" enum to be passed alongside of the event-type, passed as > a second integer? > This would reduce the size of the wire protocol, not needing to pass the > full character string, as well. > > This would trivially allow us finer grained notifications within a > particular event. > > A downside is that it may become a bit noisy for clients who may not be > interested in all of the sub-events. > Perhaps we should add some sort of filtering mechanism? Adding sub-events isn't really making it more chatty, just providing more detail to existing set of events. I gues you could optimize to let people only listen for specific sub-types, but I reckon that domain shutdown events are not frequent enough to justify this extra complexity. I'll have a go a making this adjustment... Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list