On Wed, Feb 18, 2015 at 1:33 PM, Justin Ross <justin.r...@gmail.com> wrote:
> On Fri, Feb 13, 2015 at 1:27 PM, Rafael Schloming <r...@alum.mit.edu> > wrote: > > > On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim <g...@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? > The division represents a layering in how the reactor is built. Most reactors are provided as monolithic frameworks that don't interoperate too well with each other. You pick twisted or tornado for your app, but it's awkward to use the two together in the same process. Proton's reactor is provided as a library of parts that you can use as a lightweight reactor in a standalone way, but you can also use it to more directly integrate with other reactors in a first class way. The event layer and the reactor layer represent an important division. The event layer defines all the core events and it defines the Collector abstraction as a way to gather events from those things that produce them. The Reactor provides tools for processing those gathered events, and although for the most part I think the Reactor is structured such that you could use it directly for a lot of integrations, it's also possible that for some integrations it may make sense to build on the event layer directly. > 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. > I don't think it makes too much difference for python. You really only ever need to import them once in your "main" method. Most of your app is going to be working in terms of events, and so it will just be passed a reference. In Java it might make a bigger difference since you need to import a type in order to have a variable that holds a reference to it, but I actually think that would be a much bigger factor for a lot of the other types, e.g. it wouldl probably be very awkward in java to have o.a.q.proton.event.Event since unlike in python almost every part of your app will need to import that in order to do anything useful. --Rafael
