Couple of points here...
1) If we're only interested in retrieving the latest version of data
from a subversion repository, we DON'T EVEN NEED A SUBVERSION CLIENT AT
ALL. All we need is a simple http client, as long as we limit ourselves
to one protocol, and the protocol we choose is http/WebDAV. Just use
Java's existing http classes. (but see my conclusion below for a partial
retraction...)
2) If we're interested in synchronizing the repository with our working
copy, then there's a LOT of client-side work to be done. With a JDBC
driver, its sole purpose is to retrieve data or affect server-side
changes, with a Java-based client API. Because the Java API is part of
the problem definition, it makes perfect sense for a native Java driver
to replace a JNI wrapper. With SVN, the end goal on the client side is
not access via Java API, but synchronization of a file-system-based
physical working copy using a (reasonably) stable set of rules.
The question is not only, "What's the best way for Java programs to
access Subversion?" If that were the only question to answer, then
certainly a native Java library is the best answer. In this case,
there's another related question -- "In what language should all of the
file-system manipulation for the working copy be implemented?"
I see only three possible categories of answers:
1) Java - but this makes the API available ONLY to Java developers
2) Non-Java (current) - Java developers must use JNI
3) Both - I hate to imagine the headaches trying to match the two
implementations quirk-for-quirk. Eventually one of them will outpace the
other, and we'd have a segmented community like CVS vs. CVSNT.
(My personal) conclusion:
There may be some significant value in developing a native Java
READ-ONLY client API to support the svn: protocol, and that may very
well be an interesting and worthwhile addition (or separate but related
project). I think we'd be asking for problems, though, if we were to
begin a native Java implementation of the full Subversion client API to
be maintained in parallel with the C-based one.
S_E_D
-----Original Message-----
From: treaves@silverfields.com [mailto:treaves@silverfields.com]
Sent: Wednesday, October 22, 2003 8:54 AM
To: dev@subversion.tigris.org
Subject: Re: Developing Java Client?
I wouldn't just listen to the people that have responded so far saying
that perhaps you should reconsider. The current Java API's that rely on
JNI are bad - as compared to what a native Java version would be.
Period.
Let the self-righteous rebuttal start!
There are so many problems with any JNI version of anything that it
aught
to be self-evident. But apparently it is not. So let me ask: how well
is that JNI Java port going to work on my handheld using a J2ME JVM? It
won't. Where as I will grant that not too many people will be
interested
in accessing a Subversion repository on their cell phone or Palm, there
will be times when it would be handy.
There were similar questions asked when the native JDBC drivers where
written for just about any database you care to mention: 'We already
have
CLI versions, why not simply use them and make JNI interfaces?' IBM did
this with DB2, and it was a disaster. They finally have come out with
native drivers.
And what about new platforms? The Subversion code should compile with
little modification on just about any platform, but not really. It
takes
time to port and test. With native Java drivers, as long as there is a
JVM, it'll run.
There is nothing wrong with using JNI, where JNI is the only option.
Some
of the new stuff in JDK 1.4 with the NIO even makes it better. But a
native Java version will always be faster, easier to debug, and in the
long run, easier to maintain. Look at PostgreSQL. There native JDBC
drivers are some of the best around, and are no longer second class to
the
CLI stuff.
So if someone really wants to write a native Java version, we should all
support that, and help out. In the long run it WILL happen, and it WILL
supplant the JNI version. Don't believe me? Point to one JNI interface
that still survives after the introduction of a native interface.
> OK OK ... you convinced me ... I wont do it. *surrenders* It was only
an
> idea. *shrug*
>
> In fact the general hostile reactions I have been getting on this list
> to even suggestions doesn't make me want to contribute at all..
>
> Best of luck.
>
> -- Kraythe
>
>
> "Ben Collins-Sussman" <sussman@collab.net> wrote in message
> news:m34qy22mj7.fsf@kepler.ch.collab.net...
>> "Robert Simmons" <derisor@arcor.de> writes:
>>
>> > Yes but where is the design and architecture documentation? ;-) Im
>> not terribly confidently expecting it to exist but it would be
>> convenient. Reading code to figure out architecture is very slow and
>> tedious and most people simply wont bother. If it comes down to
>> having no hints other than the code base, I may not bother. I want
>> to write a library, not learn to write C all over again.
>>
>> Read the entire Subversion book, especially chapter 7. That explains
>> a lot of architecture. There's also a very old, very general design
>> document sitting here, which gives a good overview:
>>
>>
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=259
>>
>> By the way, there is no "one protocol" for Subversion. The access to
>> the repository is an abstract API, so anyone is free to write a
custom
>> protocol. At the moment, we have a stateful custom protocol which
>> talks to an 'svnserve' server, and a WebDAV/DeltaV variant protocol
>> that speaks to an Apache server. And and there's a 'no-network'
>> protocol for accessing a repository directly. Which will you
>> reimplement in pure Java? All of them?
>>
--snip--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 16:35:28 2003