qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: proton's new event API - feedback
Date Wed, 02 Apr 2014 18:30:03 GMT
On Wed, Apr 2, 2014 at 9:17 AM, Ken Giusti <kgiusti@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message