qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject proton's new event API - feedback
Date Wed, 02 Apr 2014 13:17:30 GMT

I've been playing with the new Event/Collector engine API that's been introduced in 0.7. 
I've found this API to be a nice fit for an event-oriented project I've been hacking on for
the past few weeks:  https://github.com/kgiusti/dingus

After working with the new API for awhile, I'd like to propose a change to the API as it stands
now - I'd like to see a bit more granularity with respect to the endpoint state change events.

In the current implementation, the PN_{CONNECTION,SESSION,LINK}_STATE events are generated
only when the flags for the _remote_ endpoint state changes.  I see how this makes sense,
as the local flags are changed by the application invoking 'open()' or 'close()' - and the
application can be written to track when these calls are made.  But I'd like to avoid having
to implement this extra state tracking.

Would it be possible to issue separate events for remote and local endpoint state changes?
 For example, instead of having just a PN_*_STATE event issued when the remote flags change,
could the API issue:

 PN_*_LOCAL_EP_STATE when the local flags are modified, and
 PN_*_REMOTE_EP_STATE when the remote flags have changed?

One other minor nit: the documentation describing the PN_LINK_FLOW and PN_DELIVERY events
needs some clarity.  Specifically:

1) PN_DELIVERY is generated only when the remote disposition has changed (correct me if I'm
wrong, but this appears to be the behavior I'm observing).  This event is _NOT_ generated
when the delivery's writable state has changed (see 2). Is the event generated when the delivery
becomes 'readable'?  I haven't checked that.

2) PN_LINK_FLOW - the documentation should explain how to handle this type of event.  My understanding
is that the application should use this event to trigger processing of outgoing deliveries
that may have become writable.  This should be noted, as the event itself does not reference
a particular delivery (and, as noted above, the PN_DELIVERY event won't be generated when
it becomes writable).



View raw message