proton's new event API - feedback

[Ken Giusti <kg...@redhat.com>]

Folks,

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).

Thoughts?



-- 
-K

Re: proton's new event API - feedback

[Rafael Schloming <rh...@alum.mit.edu>]

On Wed, Apr 2, 2014 at 9:17 AM, Ken Giusti <kg...@redhat.com> wrote:

> Folks,
>
> 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?
>

Makes sense to me, although I'd probably drop the _EP_ from the names as we
don't use that elsewhere, e.g. the accessor for state is
pn_connection_state(), not pn_connection_ep_state().


>
> 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.
>

I don't think it is currently, however it could be in all those cases (or
distinct events could be generated).


>
> 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).
>
> Thoughts?
>

I've also noted that some sort of PN_*_NEW/FREE events would be handy to
provide a consistent way of doing context setup/teardown in some of my uses.

--Rafael