> 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.) > > Gordon Sim wrote: > 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.
Updated patch no longer uses the __getattr__, but instead allows different types of event to be returned from the collector. - Gordon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28770/#review64096 ----------------------------------------------------------- On Dec. 9, 2014, 11:56 a.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28770/ > ----------------------------------------------------------- > > (Updated Dec. 9, 2014, 11:56 a.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/README PRE-CREATION > 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 > >
