From users-return-11922-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Wed Feb 18 19:34:51 2015 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 351E5105D1 for ; Wed, 18 Feb 2015 19:34:51 +0000 (UTC) Received: (qmail 35258 invoked by uid 500); 18 Feb 2015 19:34:51 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 35237 invoked by uid 500); 18 Feb 2015 19:34:51 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 35226 invoked by uid 99); 18 Feb 2015 19:34:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Feb 2015 19:34:50 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of prvs=449123c383=rhs@alum.mit.edu designates 18.7.68.19 as permitted sender) Received: from [18.7.68.19] (HELO alum-mailsec-scanner-7.mit.edu) (18.7.68.19) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Feb 2015 19:34:43 +0000 X-AuditID: 12074413-f79f26d0000030e7-28-54e4e9029164 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A2.65.12519.209E4E45; Wed, 18 Feb 2015 14:33:22 -0500 (EST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (authenticated bits=0) (User authenticated as rhs@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t1IJXLkH009192 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Feb 2015 14:33:22 -0500 Received: by pabkq14 with SMTP id kq14so3501847pab.3 for ; Wed, 18 Feb 2015 11:33:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.70.23.5 with SMTP id i5mr1108406pdf.119.1424288001146; Wed, 18 Feb 2015 11:33:21 -0800 (PST) Received: by 10.70.31.194 with HTTP; Wed, 18 Feb 2015 11:33:21 -0800 (PST) In-Reply-To: References: <54DE2329.9010806@redhat.com> Date: Wed, 18 Feb 2015 14:33:21 -0500 Message-ID: Subject: Re: proton.reactors -> proton.reactor rename From: Rafael Schloming To: "users@qpid.apache.org" Content-Type: multipart/alternative; boundary=047d7bdc1c165dc6a0050f61e416 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixO6iqMv08kmIQVu/ksXZFf8ZHRg9pt55 wBbAGMVtk5RYUhacmZ6nb5fAnfHt/xnmgt8+FQceTmdrYPxk18XIySEhYCLx491cZghbTOLC vfVsXYxcHEIClxklHu9fygrh3GWS2Ln7CZTTwChxfv8GRpAWXgFBiZMzn7BAtBdIvL19gQ3E FhLwknh2bBOYzSkQKDHj+BKo5n+MEjdfb2UHSbAIqErc3bKXBWJQgMTy5ptADRwcwgKmErvO xYKE2QQ0JbZd3gg2R0TAWKJ18WtWEJsZaP7V3W2MExgFZiE5YxaS1CygScwC6hLr5wlBhNUk bm+7yg5ha0ssW/iaeQEj6ypGucSc0lzd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MkEAW 3sG466TcIUYBDkYlHt4OpichQqyJZcWVuYcYJTmYlER50x8DhfiS8lMqMxKLM+KLSnNSiw8x SnAwK4nw7tgHlONNSaysSi3Kh0lJc7AoifOqLVH3ExJITyxJzU5NLUgtgsnKcHAoSfD+eg7U KFiUmp5akZaZU4KQZuLgBBnOJSVSnJqXklqUWFqSEQ+K7fhiYHSDpHiA9rK+ANlbXJCYCxSF aD3FaMxx6eSumUwcU04cmMkkxJKXn5cqJc5rAFIqAFKaUZoHtwiWwl4xigP9LcybBVLFA0x/ cPNeAa1iAlo1/88jkFUliQgpqQbGeIl/YiXPX16VeTt9TdPMgE+hDxue6T2rOnbNKev1Krbj Z9a/mHFH5JvXOu/t79k+Ne/7LWsqMqft8uyv2cbzMjfuiq+/tbj1fqW/16rvOzT4k9i3+d7e UC8XFaq97dZJ3oDAsmdlJzmE3R7J1ey6vaJvw92/6ik8SfKc/2vFinNdZRNqnkS4KrEUZyQa ajEXFScCAPk9B2o8AwAA X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc1c165dc6a0050f61e416 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 18, 2015 at 1:33 PM, Justin Ross wrote: > On Fri, Feb 13, 2015 at 1:27 PM, Rafael Schloming > wrote: > > > On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim 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 --047d7bdc1c165dc6a0050f61e416--