Re: [libvirt] [PATCH 1/6] Introduce storage lifecycle event APIs

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