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

[Cole Robinson]

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