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 API layout proposal
Date Wed, 18 Feb 2015 15:44:02 GMT
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:


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.


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