You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2014/12/05 21:55:25 UTC
Review Request 28770: Some engine examples and supporting library code
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/
-----------------------------------------------------------
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
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
> On Dec. 5, 2014, 10:13 p.m., Rafael Schloming wrote:
> > proton-c/bindings/python/proton/__init__.py, line 3488
> > <https://reviews.apache.org/r/28770/diff/1/?file=784021#file784021line3488>
> >
> > Isn't there some redundancy here? For example this hasattr check is redudant with the clazz == "pn_session" case above.
> >
> > Presumably if you were to define the appropriate attributes (e.g. define Delivery.connection, Link.connection, etc) all of these properties would become redundant with the generic __getattr__ that you've added below this.
> >
> > I'm not sure I'm a fan of just splatting all the context properties into the event, but if you're going to do that then I would be consistent about it and remove all of these as they are essentially redundant now.
Yes, I could add properties to Delivery (Link already has one). I'd still need a test for when the context was itself a Connection, of course, but I agree it would be cleaner overall. I'll make that change.
- Gordon
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64091
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Rafael Schloming <rh...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64091
-----------------------------------------------------------
proton-c/bindings/python/proton/__init__.py
<https://reviews.apache.org/r/28770/#comment106519>
Isn't there some redundancy here? For example this hasattr check is redudant with the clazz == "pn_session" case above.
Presumably if you were to define the appropriate attributes (e.g. define Delivery.connection, Link.connection, etc) all of these properties would become redundant with the generic __getattr__ that you've added below this.
I'm not sure I'm a fan of just splatting all the context properties into the event, but if you're going to do that then I would be consistent about it and remove all of these as they are essentially redundant now.
proton-c/bindings/python/proton/__init__.py
<https://reviews.apache.org/r/28770/#comment106520>
Can you point me to some examples of why you collapsed the context namespace into the event?
- Rafael Schloming
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
> 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:
https://reviews.apache.org/r/28770/#review64096
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
> 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.
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.
- Gordon
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64096
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Rafael Schloming <rh...@apache.org>.
> 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.
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.)
- Rafael
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64096
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
> 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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Rafael Schloming <rh...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64096
-----------------------------------------------------------
proton-c/bindings/python/proton/__init__.py
<https://reviews.apache.org/r/28770/#comment106523>
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.
- Rafael Schloming
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
> On Dec. 5, 2014, 9:06 p.m., Steve Huston wrote:
> > Ship It!
>
> Steve Huston wrote:
> Great bunch of examples, Gordon! One thng that would be helpful at this point is a README to briefly describe the examples that are there and how they're paired up (send/recv, when they are).
I agree and will add one. I do actually also have the beginnings of some tutorial style text (as on the example branch). That will hopefully get on to trunk soon as well (though not included in this initial patch; I have to work out how best to integrate it in and also update it a little) but a README is useful anyway.
- Gordon
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64083
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Steve Huston <sh...@riverace.com>.
> On Dec. 5, 2014, 9:06 p.m., Steve Huston wrote:
> > Ship It!
Great bunch of examples, Gordon! One thng that would be helpful at this point is a README to briefly describe the examples that are there and how they're paired up (send/recv, when they are).
- Steve
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64083
-----------------------------------------------------------
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Steve Huston <sh...@riverace.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64083
-----------------------------------------------------------
Ship it!
Ship It!
- Steve Huston
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Rafael Schloming <rh...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64860
-----------------------------------------------------------
Ship it!
Ship It!
- Rafael Schloming
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
>
>
Re: Review Request 28770: Some engine examples and supporting library
code
Posted by Gordon Sim <gs...@redhat.com>.
-----------------------------------------------------------
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.
Changes
-------
Added a README for the examples. Altered the manner in which the uniform event interface is implemented: (1) tidied up the extra properties on Event by adding connection and session properties to delivery, (2) split out a minial EventBase from the Event class, (3) altered the collector such that if the context popped extends this base class, it is treated as an Event itself. This allows applications to define their own event classes, which I use to allow an extended event that offers the same uniform interface as the core engine events but other implementations are equally possible.
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 (updated)
-----
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