qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <justin.r...@gmail.com>
Subject Re: proton.reactors -> proton.reactor rename
Date Wed, 18 Feb 2015 18:33:24 GMT
On Fri, Feb 13, 2015 at 1:27 PM, Rafael Schloming <rhs@alum.mit.edu> wrote:

> 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.
> --Rafael

One more concern: there's a division in the current api layout that I'm
uncomfortable with, between proton.event and proton.reactor.

Is that a division we want? If it's not, I'd like to collapse them, perhaps
into proton.event?

Separately, I see some advantage in moving Reactor and Container into
proton core since I expect them to find frequent use.  I just don't want to
drag in all the related infrastructure.

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