On Fri, Dec 20, 2013 at 5:46 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:
Since I have pretty much given up on trying to work on proton, I'm not sure
that my opinion counts for much anymore... however I suppose I'm a little
curious how the JNI binding differs in extra work vs. PHP or Ruby or
such. Similarly why the API distinction is hasty when again it should
(modulo some language idiom changes) reflect the API that the C is
presenting to Ruby/PHP/Python/etc.
That's a really good question. One obvious factor is that the JNI bindings
cover the full surface of the engine API, whereas the PHP and Ruby bindings
only cover the messenger API, the latter being much smaller. The other
factor is that we have a different workflow with how we maintain the
scripting language bindings. From a design perspective each of those
bindings are more tightly coupled to the C code since that is the only
implementation they use, but from a workflow perspective each one is
actually more independent than the Java binding. When we add a feature to
the C messenger implementation we don't try to add it simultaneously across
all the bindings. It generally goes into python because that is how we
test, and it goes into perl and ruby pretty quickly after that because
Darryl is good about keeping those up to date, but, e.g., in the case of
php, we haven't tried to keep the binding at full feature parity. Finally,
the JNI binding is a bit of a different animal from the others in that it
is not just performing a simple wrapping of the C API and directly exposing
that to Java. It is adapting between the C API underneath it and the Java
API above it.
As for the hastiness, perhaps that was a poor choice of words. The problem
with the Java API/impl split is that the API was produced from an existing
implementation after the fact in order to facilitate testing. As such it
isn't well suited to be implemented by two independent implementations,
particularly one that is JNI based.
To me the fact that APIs aren't defined but that instead the only way of
knowing what a particular call should do seems to be 1) look at the code in
C and, if it's not clear, then 2) ask Rafi; is why I no longer feel it
productive to try to contribute. As such, it seems that this change is
more about vertical scaling (making it easier for Rafi, and those sitting
very near him, to work more productively), than horizontal scaling
(allowing people who are not Rafi or with easy access to him to work on
it).
Really there are two separate issues here. You're talking about conceptual
barriers to contribution, and I'm talking about mechanical barriers. Both
are barriers to contribution, and both prevent horizontal scaling. Fixing
some of the mechanical barriers to contribution does happen to also improve
vertical scaling, but as I said in my original post, I think the more
important factor is making it easier/possible for people to make complete
contributions.
FWIW, I agree we need lots of additional work around API definition and
documentation. Having more time for that is also one of the reasons I would
like to reduce some of the overhead involved in the current development
process.
Overall I don't care very much about Messenger in Java (either pure Java or
JNI), but I do care about the Engine. When the Proton Engine was first
discussed it was always said that the C code should be able to be called
from within Java as an alternative to a pure Java impl. - has this changed?
I'm fine with that as a goal, however I can't say it's a priority for me.
More importantly, as I've said before, I don't believe the use of JNI in
production is at all compatible with the use of JNI for testing purposes.
The current JNI binding exposes each part of the engine API in very fine
detail. This what you want for testing, so you can exercise every part of
the C API from Java. This is probably exactly the opposite of what you'd
want for production use though. I expect you'd want to minimize the number
of times you cross the C/Java boundary and just tie into the engine API at
key points that are shifting a lot of bytes around.
Going back to the horizontal vs. vertical scaling... If the project were
structured differently I would be very happy to contribute to the engine
side of things in Java. However I think that would require us to be
organised differently with a recognition that the Engine and Messenger are
conceptually separate (with Messenger depending on the Engine API, and
having no more authority over defining/testing the engine API than any
other client - such as the C++ broker, ActiveMQ, or the upcoming JMS clent,
etc.). As such I would rather see us fix the definition of the API (if you
believe it to be hasty) rather than simply try to remove any notion of
their being an API which is distinct from the implementation.
I'm not sure exactly what you're asking for here with respect to Messenger
and Engine. I believe they are currently
