On 12/18/2012 02:06 PM, Rafael Schloming wrote:
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. I wouldn't
be opposed to a proton-c/contrib for similar purposes, however what you're
describing sounds different. I'm assuming these libraries have no issue
depending on proton, which makes this use of contrib a kind of incubation,
which begs the question, what is the intent for this stuff once it's
hatched? Is the idea to provide another layer to the proton library itself,
or to provide something that is really an independent library with a
different focus?
If the former is the case then I think we should probably be taking a
careful look at the proposed APIs and understanding in detail what they are
and how they build on what is already there (i.e. not just shoehorn it into
contrib), and in the latter case I would say we should keep incubation to
qpid proper.
I expect that in both cases, the proposed APIs will be looked at in
detail so that their place in the world can be well understood.
Thanks for all the input. I think I'll incubate them in qpid/extras.
If we decide they should live in Proton, we can always move them. They
will either move somewhere or die from neglect.
-Ted
