[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: status of bindings via swig

From: Hans Marggraff <hmf_at_qint.de>
Date: 2002-07-22 13:03:06 CEST

Alexander Mueller wrote:
> Martin Pool wrote:
>
>>On 10 Jul 2002, Hans Marggraff <hmf@qint.de> wrote:
>>
>>
>>>I have made an attempt at connecting java to svn with the intention
>>>of writing a java gui client.
>>>
>>>
>>
>>Perhaps it would be easier to do the first version of your GUI with
>>the Java code just running the svn command and parsing stdout/stderr?
>>Once you're happy with that, you could convert to jni/swig if it was
>>necessary for speed.
>>
>>Just an idea.
>>
>>
>>
> +1 Thought about this as well. Is probably more pragmatic than trying to
> catch the api interface train and handle the JNI at the same time
>
I will probably go that way. Not that I like it really.
The necessity of this in my eyes is a flaw in the Subversion api design.
I think is is too low level. I believe an API should not expose
details lime apr-pools. This requires a user of the api to adapt
to the memory management approach of subversion. A higher level api
in my eyes should hide this and rather expose the semantics of the data
that goes across the interface in the most simple form. E.g. char** filelist instead of an opaque pool object or baton.
And then the caller would be responsible for her memory management and the svn library for
its.

Maybe it makes sense to define this more abstract api first and then base the Java binding on it.

Still currently this is probably the way to go.

-- 
Hans Marggraff
Qint Software
Allingerstr. 18a
82178 Pucheim
Germany
Tel 089 80067094
mailto:hmf@qint.de
http://www.qint.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 22 13:04:18 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.