qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Proton API layout proposal
Date Wed, 18 Feb 2015 16:18:31 GMT
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'.

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 

> 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.

> 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?

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message