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 17:56:13 GMT
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim <gsim@redhat.com> wrote:

> On 02/18/2015 03:44 PM, Rafael Schloming wrote:
>> 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/
> I think that post describes the criteria for accepting something into the
> 'blessed' contrib namespace. They don't describe why they called it
> contrib. They describe it as 'extra, optional, tools' or in the link above
> 'optional, de facto standard implementations of common patterns'.

No, and that's not why I referred to it. I assume the origin of calling it
contrib started back somewhere in the annals of unix history, and is likely
not super relevant to how it is actually understood today (like /etc, /opt,
and so forth). That doesn't change the fact that at least among some people
it has a pretty commonly understood meaning that is a good match for our

> So extras or indeed optional would seem equally appropriate and to me,
> less confusing.
>  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 don't think that is the same at all. The current contrib structure is a
> top level directory under which you have proton-jms and proton-hawtdispatch.

I think the use of the term contrib as a bucket and the criteria that is
applied to what goes into that bucket is (or should be) the same. The fact
that each of the units currently in the bucket have something more specific
that makes sense as a top level package name doesn't really change that,
the term is being used in the same way, just for adding structure in the
source tree rather than for adding structure in an API package.

>  I do get the impression that there is possibly an unspoken bias against
>> contrib,
> Unspoken? I said quite clearly I don't like it. To me it has no more
> meaning than say extras or optional, and the actual meaning of the word
> doesn't in my view match what we are talking about.

Sorry, my comment was unclear. I was actually referring to Justin's
implication that putting something in contrib is somehow disowning it, not
commenting on your dislike of the term.

>  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.
> I very much dislike it. However if you are adamant on that name, would
> messenger be relocated there also?

I'm actually not at all adamant on the name, however I am pretty adamant
about consistency and avoiding churn. Regardless of what terminology we
choose, I think the important thing here is to clearly communicate what the
term implies. The post I pointed to actually does a pretty good job of
this, and I think having two separate terms to mean the same thing is
strictly worse for users than having one term. If you feel that using the
term "extras" instead of "contrib" is going to improve our user experience,
and you want to put the time in to change our existing usage of contrib
over to extras, then I have no objection. To be perfectly clear though, I
do object to introducing the term extras, defining it to mean almost the
same thing as contrib, and ignoring the existing usage of contrib. I think
this just creates more confusion.

Regarding where messenger should be located, it depends on whether you
consider it "optional". If so, then I would actually say it's analogous to
the hawtdispatch and jms examples, and build-wise it would be completely
consistent to put it alongside them, particularly if that would enforce the
layering constraint. I would leave the actual package name though since
just like the hawtdispatch/jms modules it has enough of a well defined name
and purpose that it doesn't really need to be bucketed from an API


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