On Wed, Jan 23, 2013 at 8:01 AM, Keith W <keith.w...@gmail.com> wrote:
> 3. To change proton-api, all that is required is to edit a Java file.
> - Developer productivity
This seems to be kind of a leading requirement so to speak, or at least
it's phrased a little bit oddly. That said I would never argue with it for
most of the Java files, however in the case of the API files I don't see
how you're ever going to be able to stop after just editing the API.
Because we have two implementations, we're fundamentally stuck with
manually syncing the implementations themselves whenever a change to the
interface occurs. By comparison the highly automatable task of syncing the
API files themselves seems quite small. I'm imagining most changes would go
something like this, say we want to add a getter to the Message interface,
we would need to:
1. edit the Message interface
2. write and/or possibly modify a test
3. edit the java Message implementation
4. run the tests against java, if they don't pass go to step 2
5. now that the java impl passes the tests, run the tests against the C
6. if the sync check fails on the C build, run the sync script
7. edit the message.h file
8. edit the message.c implementation
9. edit the adapter layer between the C API and the Java interfaces
10. run the tests against the C, if they don't pass go to step 8
11. run the tests against both, just to be sure
12. check in
Given the above workflow, it seems like even with a relatively small change
like adding a getter, the scripted portion of the syncing effort is going
to be vanishingly small compared to the manual process of syncing the
implementations. Perhaps I'm just envisioning a different workflow than
you, or maybe I'm missing some important scenarios. Could you describe what
workflow(s) you envision and how the sync process would impacting your
> 4. To switch to a particular SVN revision, simple SVN commands are run
> (e.g. svn switch or svn update)
> - Developer productivity
> 5. proton-c can be built, excluding its JNI binding, without requiring
> non-standard tools*
> 6. proton-c can be built, excluding its JNI binding, from a standalone
> checkout of the proton-c directory
> - Developer productivity / tool familiarity
> 1. A "tarball" source release of proton-c can be built by a user
> without an external dependency on any other part of proton, e.g.
> 2. The aforementioned proton-c tarball release can be produced by
> performing a simple "svn export" of proton-c.
> - If I were building proton-c for my platform for tarball, I would
> also want to run the tests to be sure proton-c functions correctly.
> For this reason I question the usefulness of a proton-c tarball. I
> would want a tarball that included the whole tree including the tests.
The proton-c tarball does include the tests directory. The tests directory
is just pure python code, so once you've installed proton-c onto your
system, you can run any of the proton tests just like you would run any
normal python script. As I mentioned in another post, the inclusion of
tests under both proton-c and proton-j is the one deviation in directory
structure from a pure svn export, and even this much is kindof a pain as
there is no way for the README to actually describe things properly without
being broken in either the svn tree or in the release artifact.
> 7. Proton-c can be built without requiring non-standard tools*
> 9. Proton-c can be tested without requiring non-standard tools*
> - If we can achieve this without introducing too much complexity,
> reinventing too many wheels and the result is portable across all
> target platforms.
> 8. proton-c can be built from a standalone checkout of the proton-c
> - I think that all proton developers who are changing either the C or
> Java implementations should be running the system tests before each
> commit. If they are changing system tests then they need to run
> against both implementations before each commit.
Doesn't this conflict pretty directly with 6?