qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: proton.reactors -> proton.reactor rename
Date Fri, 13 Feb 2015 18:27:50 GMT
On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim <gsim@redhat.com> wrote:

> On 02/13/2015 03:00 PM, Rafael Schloming wrote:
>> This has come up tangentially in a couple of threads now, and there seems
>> to be at least tacit agreement that the plural doesn't make sense anymore
>> now that we've seen how integrations/extensions will work.
>> I'll be posting an alpha later today, but before that I'd like to do the
>> reactors->reactor rename of the python package to keep everything
>> consistent. This stuff hasn't been in a release yet, so I don't think
>> there
>> are any backwards compatibility issues, but if this will cause problems,
>> please follow up and I will create an alias.
> Just a suggestion, but what about proton.reactive? Perhaps proton.
> handlers could then be proton.reactive.handlers, which would make the
> relationship clearer.

I'm fairly neutral on proton.reactive vs proton.reactor. I do kind of like
the notion of a "proton.reactor", mostly because it sounds like something
awesome that is used to power starships, however that isn't a huge deal.

I'm less of a fan of nesting handlers, partly just because it's longer, and
partly because it complicates the mapping to the C API which like most C
APIs is just flatter.

Another option favoring conciseness and consistency with C might be to get
rid of the "reactor" portion entirely:

  - proton.Reactor, proton.Container, and proton.handlers.*

All in all I'm not super fussed, I could probably live with any of the
options. I did already do the reactors->reactor rename, but it's easy
enough to do it again if any of the above seem significantly preferable.


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