qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Sim" <g...@redhat.com>
Subject Re: Review Request 28770: Some engine examples and supporting library code
Date Mon, 08 Dec 2014 14:27:34 GMT

> On Dec. 5, 2014, 10:24 p.m., Rafael Schloming wrote:
> > proton-c/bindings/python/proton/__init__.py, line 3542
> > <https://reviews.apache.org/r/28770/diff/1/?file=784021#file784021line3542>
> >
> >     To expand on my question here, I'd also like to understand if this __getattr__
is just an expedient way of copying a specific set of attributes from the context into the
event or if it is actually your intent to flatten any arbitrary context properties into the
event object.
> Gordon Sim wrote:
>     What I want is a 'uniform' interface to an event. I.e. rather than the event-type
dependent context being the only thing directly exposed, I'd like the connection property
to be available for any event that is in any way associated with a connection (even if it
is say a delivery- or link- event), likewise for sessions and links. So whether I'm handing
an incoming message, a change in credit, or perhaps even a change in endpoint state, I can
get the relevant objects via the same property rather than having deducing the context type
and figure out how to get what I want from that.
>     I'd like to be able to keep this same interface even for 'extended' events created
outside the core engine - e.g. perhaps a timer for retrying a disconnected connection, or
an application defined event indicating availability of data to send on a given link. The
extended events however may additionally have some other properties.
>     So getting back to the question now the high level goal is (hopefully!) explained,
the context seems to me like an internal detail. What I care about as a user is getting the
connection or link or session or foo from the event. The context is just the mechanism that
makes this work via swig etc. As a user I don't want to distinguish between context and the
event itself.
> Rafael Schloming wrote:
>     If you don't want to distinguish between the context and the event, then why pass
the event around in the first place? I believe in an earlier incarnation of the examples I
had the dispatch mechanism set up to pass the context directly into the handler rather than
passing in the event. I believe at the time you said you preferred passing around the event
because it is more flexible, e.g. we can pass in extra info without changing the signature
of the handler. This same argument would suggest to me that you do actually do want to distinguish
between the context and the event itsef.
>     To be clear I'm not against having convenience accessors as you describe, however
I don't think it's a good idea for the getattr to actually exposing *everything* in the context
onto the event. It makes it unclear to me whether "Event" is actually exposed as a first class
thing for users or not. If it's not then I think it's better to eliminate it during the dispatch
process and just pass around the context. If it is then I think it's better to explicitly
define exactly what properties an event has for every given event type.
>     As you have it, the current shadowing behavior can lead to confusing situations,
e.g. I'm guessing you can probably write code that pretends the event actually *is* the connection,
e.g. do things like event.open(), event.close(), etc, but stuff like event.hostname = "blah";
event.open() would fail silently since the hostname attribute would get set on the event,
but the open method would get called from the connection. (Note I haven't actually tried the
previous example, so please correct me if I'm mistaken.)

Clearly the event is different from the connection it occurred on, so my choice of phrasing
there was poor.

What I'm trying to explain is the difference between having to understand what the context
is for different events, versus just having some common properties of an event that are used
whenever that property is relevant. E.g. event.connection vs. event.context, or event.context.connection
or event.context.session.connection. I like thinking of the associated connection as simply
a property of the event, one that is always there for connection-relevant events.

I'm certainly open to better ways of accomplishing the same thing. The uniformity is the most
important aspect to me.

- Gordon

This is an automatically generated e-mail. To reply, visit:

On Dec. 5, 2014, 8:55 p.m., Gordon Sim wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28770/
> -----------------------------------------------------------
> (Updated Dec. 5, 2014, 8:55 p.m.)
> Review request for qpid and Rafael Schloming.
> Repository: qpid-proton-git
> Description
> -------
> These are the current reactive examples using the engine API, that I have been evolving
on the examples branch, alog with the utility code they depend on. I still need to evolve/rationalise
the examples themselves as well as the utility code, but I believe it would be beneficial
to all to do this from the master branch.
> Diffs
> -----
>   examples/engine/py/abstract_server.py PRE-CREATION 
>   examples/engine/py/client.py PRE-CREATION 
>   examples/engine/py/client_http.py PRE-CREATION 
>   examples/engine/py/common.py PRE-CREATION 
>   examples/engine/py/db_common.py PRE-CREATION 
>   examples/engine/py/db_ctrl.py PRE-CREATION 
>   examples/engine/py/db_recv.py PRE-CREATION 
>   examples/engine/py/db_send.py PRE-CREATION 
>   examples/engine/py/helloworld.py PRE-CREATION 
>   examples/engine/py/helloworld_blocking.py PRE-CREATION 
>   examples/engine/py/helloworld_direct.py PRE-CREATION 
>   examples/engine/py/helloworld_direct_tornado.py PRE-CREATION 
>   examples/engine/py/helloworld_tornado.py PRE-CREATION 
>   examples/engine/py/proton_server.py PRE-CREATION 
>   examples/engine/py/proton_tornado.py PRE-CREATION 
>   examples/engine/py/recurring_timer.py PRE-CREATION 
>   examples/engine/py/recurring_timer_tornado.py PRE-CREATION 
>   examples/engine/py/selected_recv.py PRE-CREATION 
>   examples/engine/py/server.py PRE-CREATION 
>   examples/engine/py/server_tx.py PRE-CREATION 
>   examples/engine/py/simple_recv.py PRE-CREATION 
>   examples/engine/py/simple_send.py PRE-CREATION 
>   examples/engine/py/sync_client.py PRE-CREATION 
>   examples/engine/py/tx_recv.py PRE-CREATION 
>   examples/engine/py/tx_recv_interactive.py PRE-CREATION 
>   examples/engine/py/tx_send.py PRE-CREATION 
>   examples/engine/py/tx_send_sync.py PRE-CREATION 
>   proton-c/bindings/python/CMakeLists.txt 6be421e237f86f2aa99c23ffbc08af821b5c8438 
>   proton-c/bindings/python/proton/__init__.py fce3255bfce440dcae57457d259147a4ced8216e

>   proton-c/bindings/python/proton/handlers.py PRE-CREATION 
>   proton-c/bindings/python/proton/reactors.py PRE-CREATION 
>   proton-c/bindings/python/proton/utils.py PRE-CREATION 
> Diff: https://reviews.apache.org/r/28770/diff/
> Testing
> -------
> All examples have been tested, note that the transactional examples require a couple
of extra proton-c patches (available on respective JIRAs) in order to run correctly.
> Thanks,
> Gordon Sim

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