On 06/10/2016 10:44 AM, Ján Tomko wrote: > 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'd rather not add more to the pile... ccing danpb for his thoughts Thanks, Cole >> 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