Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of
 prvs=64917ff0ce=rhs@alum.mit.edu designates 18.7.68.20 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E4A73C.8040709@redhat.com>
References: 
 <CANVjZ_QyddagwL8mtOyZHPcnC1VU+3+Tg__-iQOQu2pWc_sjYw@mail.gmail.com>
	<CACL1BnC0LQqE+E5+m1e3y+BpWZ1qv0A4PcMuHN87y+NkYEmpZw@mail.gmail.com>
	<CANVjZ_TYMrgNs7pdkh37aHA0rjpP_d1ETnXYrKT91ipcxjrsMg@mail.gmail.com>
	<CACL1BnBJqbrZL0TS7gTOBL6PbVUYxqU_p-8xTL1Veaw7CoeZVQ@mail.gmail.com>
	<CANVjZ_QUO3bpN6gaf-5M=2NyGzVAyTmXZ8FaqNB+u6rRJU1i0A@mail.gmail.com>
	<CACL1BnBRm2DBkNQQNmP1toNL6pNv3Kh4qt4Ji0dwJd1-5v_Qxw@mail.gmail.com>
	<CANVjZ_R3cezfeN8V9itSHnkh=FAjJR1FS7k_54Nitn_LCA0dSw@mail.gmail.com>
	<CANVjZ_RuEgov3ZU1+UZh5eRMu3GxAFT2Ks0rEdP387njh=qruw@mail.gmail.com>
	<54E458E2.1080105@redhat.com>
	<CACL1BnCANqtSHQFfUb0ip9iioe=FYKdURRbxRp-=_86=voWHAA@mail.gmail.com>
	<54E4A73C.8040709@redhat.com>
Date: Wed, 18 Feb 2015 10:44:02 -0500
Message-ID: 
 <CACL1BnD2+MMf2rDbuUST-bm8WF2k_i-B7k62a1mv-yfMKfyjMg@mail.gmail.com>
Subject: Re: Proton API layout proposal
From: Rafael Schloming <rhs@alum.mit.edu>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc1c1646f08b050f5eb0b4

--047d7bdc1c1646f08b050f5eb0b4
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 18, 2015 at 9:52 AM, Gordon Sim <gsim@redhat.com> wrote:

> On 02/18/2015 02:28 PM, Rafael Schloming wrote:
>
>> On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim <gsim@redhat.com> wrote:
>>
>>>   To amplify a little, the point was that the two things currently in the
>>> utils module are ways of adapting the reactive, non-blocking,
>>> event-driven
>>> style to some other style (messenger is in my view a similar sort of
>>> thing). Though it is certainly more narrow, I think its also more
>>> helpful.
>>>
>>> The other aspect to these is that they aren't yet considered as
>>> fully-baked as the reactive core. I certainly don't object to them being
>>> in
>>> an extras namespace to denote that, until we are more comfortable we have
>>> the interfaces right. You could also however indicate that through
>>> documentation or some 'experimental' annotation.
>>>
>>
>>
>> I agree we don't necessarily need to signal bakedness in the package name,
>> I think it's good to think of it as an orthogonal dimension. I'm not quite
>> sure I follow the reasoning for proton.adapters though. That sounds to me
>> like somewhere we'd put stuff for integrations, e.g. maybe the tornado
>> stuff.
>>
>
> I see these things as providing an alternative API on top of the reactive
> style API. Which to me is what an adapter does.
>
> To me the tornado integration is more of a plugin.
>
> I'm not adamant about the 'adapters' name though, just saying its clear to
> me(!). I really don't like 'contrib' though. For one thing it makes no
> logical sense to me. How are things more 'contributed' than anything else?
> I think 'extras' is actually a clearer way to describe the layering you
> mention. I don't mind that, though it is a little vague. (I think an
> adapter is also clearly layered).


I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a pretty common
convention. There's a post here that describes django.contrib in much the
same terms:

   http://jacobian.org/writing/what-is-django-contrib/

If we didn't already use the contrib convention I wouldn't actually care
all that much, but I feel like we should at least be consistent within our
own codebase, so if we introduce python.extras, that's pretty much pushing
for a rename of the java contrib stuff which seems like unnecessary churn
at this point.

I do get the impression that there is possibly an unspoken bias against
contrib, i.e. that's just a bucket to stick unwanted contributions, but I
really don't think we should view it that way. I think the comments in the
post above about it only containing best practices and what not are
something we should take to heart.

--Rafael

--047d7bdc1c1646f08b050f5eb0b4--