On Fri, Jun 10, 2016 at 09:57:13AM -0400, Cole Robinson wrote:
On 06/10/2016 09:50 AM, Ján Tomko wrote:
On Fri, Jun 10, 2016 at 08:30:33AM -0400, Cole Robinson wrote:
On 06/10/2016 07:05 AM, Ján Tomko wrote:
On Thu, Jun 09, 2016 at 05:43:05PM -0400, Cole Robinson wrote:
The 'Any' suffix can also be dropped.
There is no legacy virConnectStoragePoolEventRegister API so we don't
need to add suffixes like we had to for virConnectDomainEventRegister.
You mean the internal driver name 'connectStoragePoolEventRegisterAny', not
the public API?. If so that sounds fine to me, but I'm not sure how much
precedent there is for having driver function names differ from the public API
names
I meant both the public API and the internal driver name.
I disagree, that will make the public API inconsistent across object types. We
would end up with basically
DomainEventRegister(conn, cb)
DomainEventRegisterAny(conn, obj, eventID, cb)
NetworkEventRegisterAny(conn, obj, eventID, cb)
StoragePoolEventRegister(conn, obj, eventID, cb)
So not only would the preferred API not have consistent naming, the similarly
named APIs would have different signatures.
I don't think that's a problem. Such inconsistency is consistent with
all the other inconsistencies in our API naming. :)
I don't think that's worth it to
to get slightly nicer named APIs for storage events
Not just storage pool events, all the future events too.
(Right until someone comes up with EventRegisterModern or
EventRegisterParams).
Jan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list