qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: reactor examples
Date Thu, 12 Feb 2015 14:58:45 GMT
On Thu, Feb 12, 2015 at 8:29 AM, Gordon Sim <gsim@redhat.com> wrote:

> On 02/05/2015 05:10 PM, Rafael Schloming wrote:
>
>> On Wed, Feb 4, 2015 at 8:39 PM, Ted Ross <tross@redhat.com> wrote:
>>
>>> I'm a bit confused by this push.  How does this set of examples relate to
>>> the examples Gordon has been developing in examples/engine/py?
>>>
>> [...]
>
>> The short summary is that I've worked to implement in C a lot of the
>> concepts Gordon already developed so that we can gain the benefits of his
>> work across all languages, not just Python.
>>
>
> I didn't really develop any concepts. I focused on getting a set of
> working examples that demonstrated a level of usability and functional
> completeness I believe is necessary, along with utilities (essentially some
> handlers and a 'container' class) that enable this. The examples and the
> utilities are currently in python.
>

Concepts might not be quite the right word, but you did develop most of the
dispatch model necessary to support the simplified scenarios (scoped
handlers, derived events, etc). My hope is by providing this model in C we
can a) keep the model consistent across all the bindings and b) give them
all a head start when it comes to implementing something similar, i.e. they
can focus just on whatever convenience layer makes the most sense for that
given language and not have to redevelop the same plumbing.


> Ultimately, we'll want to
>> reconcile the Python container with the C Reactor. As you point out they
>> are actually quite close already.
>>
>
> The purpose of the container (as well as being the simple entry point for
> applications), was as a place to locate the convenience functions for
> connecting, establishing links etc, that allow applications to remain
> succinct and (I hope) intuitive. I.e. the important difference is exactly
> what the container is seeking to add.
>
> What the reactor replaces is the plumbing that was necessary to drive
> everything. The container can be viewed as a layer on top of that or an
> extension to it.
>
>  Gordon and I have discussed how some of
>> the remaining differences can be reconciled. I'll be posting some notes on
>> this in the next few days.
>>
>
> I have all the 'container'  examples working over the reactor now. There
> is a small change to the reactor itself to allow for more flexibility in
> configuration of ssl and sasl:
>
> https://reviews.apache.org/r/30926/
>
> There is a trivial temporary workaround for the lack of sufficient
> transport events being emitted when using ssl:
>
> https://reviews.apache.org/r/30927/
>
> Then there are a couple of small additions to the python wrapped version
> of the reactor:
>
> https://reviews.apache.org/r/30928/
>
> https://reviews.apache.org/r/30929/
>
> With these in place the two attached patches will apply and complete the
> work (I'm not sure how to put patches up on reviewboard that depend on
> other patches). The only real change to the api is that the schedule method
> takes a relative duration, where previously it took an absolute time. It
> also allows a handler to be specified for the specific scheduled event. I
> think these are both improvements.
>
> (I split the attachments into two to make it easier to review. The first
> is an entirely non-functional change that simply moves code, unaltered.
> This makes it clearer that there are no further changes to the reactor. As
> a single diff it was a lot harder to read).
>

I'm +1 on all the patches (both reviewboard and attached).

--Rafael

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