On 02/18/2015 05:56 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim <[email protected]> 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
purpose.
I am not one of those people, but perhaps I just lack some cultural
context or other. I don't think its a unix convention though.
[...]
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.
The existing 'usage of contrib' appears to simply be the directory name,
and two references to that from the top level pom.xml, its not sued in
anything most users will even see, so the 'churn' thing seems somewhat
overstated.
I don't find the consistency argument terribly convincing either, since
what is being proposed as I understand it - a contrib module for
undefined 'stuff' within the proton package - seems to me to be
inconsistent with existing usage anyway.
As for communication as to what the term implies, the contrib directory
was requested in https://issues.apache.org/jira/browse/PROTON-140.
Unfortunately the irc snippet included doesn't provide much insight into
the motivation and I haven't been able to find anything about the
described F2F conversation either.
In the one thread I was able to find on the subject you state[1]:
The proton-j/contrib directory was created to hold
glue/integration with established third-party libraries
/apis (specifically jms and hawtdispatch). The fact that
hawtdispatch and jms don't want a proton dependency, and
proton doesn't want a jms or hawtdispatch dependency kind
of forces the glue/integration to sit somewhere separate
from each, and since it is kind of silly to have an
entirely separate project just for that glue/integration
code, creating a proton-j/contrib made sense.
The things we are talking about are not 'glue/integration with
established third-party libraries/apis' nor do they have extra
dependencies.
However this is really just saying that I find the arguments for contrib
unconvincing. Since you clearly don't like extras - and for that matter,
neither do I - let's come up with a name that is a more functional
description of the classes in question.
What about 'sync' or 'synchronous'?
[1]
http://mail-archives.apache.org/mod_mbox/qpid-proton/201212.mbox/%3ccacl1bndrkdv07rnbzv7ewgmsue4ftfr6sfnfxz52y8wlrvp...@mail.gmail.com%3E
Regarding where messenger should be located, it depends on whether you
consider it "optional".
It clearly *is* optional (under the usual definition of that term).
Would you consider it non-optional, i.e. required?
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
perspective.
It is currently in the proton package, so I think you would have to
change that if you moved it into a different part of the tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
