You think I lose because we're not playing the same game.
Interesting that most feedback so far refers to the CLI approach and not
to the GUI itself...
I'm not trying to build a Subversion API better than JNI or SWIG; I'm
trying to build a GUI that abstracts from Subversion commands or API
functions and focuses on user interaction.
Generating CLI commands and parsing the output is usually the last
resort when you don't have an API. (E.g., I once wrote a
process-oriented GUI frontend for Clearcase 3.x (before UCM), and at
that time the CLI was the only choice.)
I will stop using the CLI from the Supervision Java GUI and use any Java
wrapper around libsvn_client as soon as
* there is a stable and complete Java API (and I don't care if its
generated via SWIG or hand-coded in JNI)
* the Java classes and any required native libraries are built and
installed automatically with Subversion's build process and are by
default contained in precompiled Subversion packages.
As far as I can see, there are three attempts at creating a Java API,
(1) using SWIG in subversion/bindings/swig
(2) using JNI directly in subversion/bindings/java/jni (or does this
depend on (1)? I don't think so, but I'm a bit confused by the READMEs
(3) another hand-coded JNI library in the svnup project.
...all of them not really ready to use out-of-the box.
Had I started my GUI with one of these APIs, I would have made little
progress with the GUI itself and would still be dealing with the API.
Branko Čibej schrieb:
>
> Here's what you say:
>
> * You cannot simply run your Java application on another platform;
> you have to recompile the native library first.
>
> You cannot simply run your Superversion GUI on another platfrom, you
> have to recompile the command-line client first.
>
What is the percentage of Subversion installations with
A) a fully functional Java API?
B) a fully functional CLI?
I am developing the Supervision GUI on Linux. To test it on Windows, I
simply grap a Subversion installer package, install it and double-click
my Jar file. I don't have a C compiler for Windows, and I don't even
have Windows at home ;-)
> * JNI programming (and debugging) is rather hairy.
>
> But of course, you don't have to *do* any JNI programming, because we
> use SWIG to generate the JNI wrappers.
This will hopefully be true some day when the Java-SWIG bindings are
complete. But this is not currently the case, going by the number of
FIXMEs in swigutil_java.c
> And of course, it's not exactly
> easy to debug into a CLI from a Java GUI, either.
>
My idea was to leave CLI debugging to the CLI developers :-) The CLI is
stable enough for my purposes; to debug the GUI, I simply trace the
commands it generates and the output received from the CLI.
> * The Subversion Client API seems to be less stable than the
> Subverson CLI; thus, a GUI built on top of JNI runs the risk of
> not being usable with the latest subversion release.
>
> I don't see where you got that from.
I tried building the svnup-0.1 snapshot against two Subversion releases
I had on my box, and I failed in both cases. I had to get the exact
Subversion revision used by the svnup team.
Running my GUI via the CLI on any of these Subversion revisions has not
been a problem so far.
> Both the client API and the CLI
> will change in various ways before 1.0, so you have to track the
> changes in any case. The difference is that when the CLI changes, *you*
> have to figure out how to fix your parser; but when the client API
> changes, SWIG just generates new bindings and the compiler tells you
> what to change.
>
> Score: 1.5:3
>
>
> And finally, using the native API lets you do nice things (such as
> cancellation and progress reporting) that the CLI simply cannot.
>
> Score: 1.5:4. You lose. :-)
>
>
See above: you're trying to sell me something you don't have yet (which
is what most software shops thrive on....). I'll be happy to buy it --
especially when it's free :-) -- but let's talk about that again when
your toy (i.e. the Java/SWIG bindings) is finished, and in the meantime,
I'll continue building mine...
Replacing the CLI wrapper in Supervision by some other Java API at a
later stage will be a matter of writing a few adapter classes. This is
fairly straightforward and will have no impact at all on the front end.
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 11 23:59:12 2003