Language Advocacy

[Bruce Atherton <br...@flair.law.ubc.ca>]

I wonder if we could drop the language advocacy on the list. I think most 
of us understand the following:

   - TMTOWTDI = ease of expression
   - TMTOWTDI = maintenance nightmare, since other peoples' idioms will not 
be your own (Perl is the PL/I of the modern world in this respect)
   - No part of Subversion itself should be written in Perl
   - There is a need for Perl bindings to the Subversion library.

Now that we are all agreed, let's move on.

At 10:16 AM 02/03/2001 -0600, pohl wrote:
>While we're on the subject of language bindings, I'd like to ask if
>anybody here has considered how one would write a client class library
>in Java? Would it require maintaining separate implementations in
>Java of both Neon and libsvn_ra_dav of one didn't want to go the
>less-portable JNI route?

I think it depends on which libraries you are talking about.

Regarding the FS libraries, I believe that JNI is required in order to get 
at the Berkeley DB libraries. The bindings are created as part of the 
standard build from Sleepycat. Furthermore, given the portability goals of 
Apache and Subversion, I'm not sure how much more portability a pure Java 
solution would give you.

If your concern is for clients using the network layer, you probably don't 
want to require them to do any kind of compilation so you have to deliver 
Java bytecode and possibly (if using JNI) compiled binaries for each 
platform. So there is a real advantage to avoiding JNI on the client, in 
that you don't have to provide many different binaries.

If you want to avoid JNI you will need a library that talks DeltaV. For 
ease of understanding and reuse, it would probably be helpful if 
libsvn_ra_dav was reimplemented in Java as well, although there is no 
reason it would have to be. The Java client could just as easily call 
directly into the DeltaV library.

There are a number of projects that are developing WebDAV libraries in 
Java, such as Jakarta Slide http://jakarta.apache.org/slide/index.html, 
Websphere DAV4J http://www.alphaworks.ibm.com/aw.nsf/techmain/DAV4J, and 
WebDAV Explorer http://www.ics.uci.edu/~webdav/. Jakarta Slide even 
specifically mentions their intention to include DeltaV client support. 
None of them currently support DeltaV that I could find, though.

That is my take on it, anyway.

Java bindings (was: Re: Language Advocacy)

[Greg Stein <gs...@lyra.org>]

On Fri, Mar 02, 2001 at 09:48:43AM -0800, Bruce Atherton wrote:
>...
> At 10:16 AM 02/03/2001 -0600, pohl wrote:
> >While we're on the subject of language bindings, I'd like to ask if
> >anybody here has considered how one would write a client class library
> >in Java? Would it require maintaining separate implementations in
> >Java of both Neon and libsvn_ra_dav of one didn't want to go the
> >less-portable JNI route?
> 
> I think it depends on which libraries you are talking about.
> 
> Regarding the FS libraries, I believe that JNI is required in order to get 
> at the Berkeley DB libraries. The bindings are created as part of the 
> standard build from Sleepycat. Furthermore, given the portability goals of 
> Apache and Subversion, I'm not sure how much more portability a pure Java 
> solution would give you.

I'd see the use of Java as a preference in this case; portability may not be
required. I know that I write much of my own stuff to always run on Linux; I
use Python primarily, but not so that it'll run on a Palm Pilot.

>...
> If you want to avoid JNI you will need a library that talks DeltaV. For 
> ease of understanding and reuse, it would probably be helpful if 
> libsvn_ra_dav was reimplemented in Java as well, although there is no 
> reason it would have to be. The Java client could just as easily call 
> directly into the DeltaV library.

Right. Our use of WebDAV was intended to facilitate the use of standard
libraries and tools. While we will provide client-side libraries to
bootstrap peoples' code, they may still choose to "go to the metal" and use
DeltaV libraries to directly interface with the SVN server. Great for them;
it is part of our design. (no custom protocol requiring custom development)

> There are a number of projects that are developing WebDAV libraries in 
> Java, such as Jakarta Slide http://jakarta.apache.org/slide/index.html, 
> Websphere DAV4J http://www.alphaworks.ibm.com/aw.nsf/techmain/DAV4J, and 
> WebDAV Explorer http://www.ics.uci.edu/~webdav/. Jakarta Slide even 
> specifically mentions their intention to include DeltaV client support. 
> None of them currently support DeltaV that I could find, though.

SkunkDAV at SourceForge is (apparently) a very good WebDAV client library.

Last I checked/heard on these: Slide is a framework, and doesn't have a
complete implementation; DAV4J has had some problems (dunno what; I should
learn more); WebDAV Explorer doesn't have a separable library. SkunkDAV is
intended to be a separable library plus a GUI app.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Language Advocacy

[Bruce Atherton <br...@flair.law.ubc.ca>]

At 06:35 PM 02/03/2001 -0500, Jim Blandy wrote:

>Not sure what you mean here.  Code that uses the Subversion filesystem
>library need never make a single Berkeley DB call --- svn_fs.h
>provides a complete covering for Berkeley DB.  So I don't see why the
>fact that the FS uses Berkeley DB internally affects how one must
>write Java bindings for it.

What I meant was that if you wanted to write a client that interacted with 
the Subversion file system rather than through network calls, you could not 
do it in pure Java but require JNI bindings. That is true even if you 
recreate all the FS code in Java, because the Berkeley DB code requires JNI 
bindings (as I understand it). Of course, you could try to recreate 
Berkeley DB in Java as well, but that would be no small undertaking.

Re: Language Advocacy

[Jim Blandy <ji...@zwingli.cygnus.com>]

Bruce Atherton <br...@hagbard.flair.law.ubc.ca> writes:
> Regarding the FS libraries, I believe that JNI is required in order to get 
> at the Berkeley DB libraries. The bindings are created as part of the 
> standard build from Sleepycat. Furthermore, given the portability goals of 
> Apache and Subversion, I'm not sure how much more portability a pure Java 
> solution would give you.

Not sure what you mean here.  Code that uses the Subversion filesystem
library need never make a single Berkeley DB call --- svn_fs.h
provides a complete covering for Berkeley DB.  So I don't see why the
fact that the FS uses Berkeley DB internally affects how one must
write Java bindings for it.