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