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

Re: Moving bindings into a separate project.

From: Brian Denny <brian_at_briandenny.net>
Date: 2004-02-22 12:59:27 CET

On Sat, Feb 21, 2004 at 01:56:32PM -0800, Ben Reser wrote:
> I agree with Justin that the bindings should at some point be treated
> the same as the C API. In fact doing so would be a great strenth to
> this project. Already such important tools as viewcvs depend upon these
> bindings. Providing the same compatability guarantees will cause more
> applications to be built upon the bindings and will make the subversion
> project core even more valuable and useful.

Most of what you say makes sense to me, Ben, but...

"The bindings". There's an awfully large set of potential language
bindings out there. Which ones are 'essential'? Right now it seems
easy to answer that question: the small handful that are fairly
well-developed already. But what about down the road? What if a couple
of people get the Ruby bindings together and caught up with the C API?
Do those then become 'essential' too? Is there a limit to the number of
bindings that can be considered 'essential', given that each one then
carries the risk of holding up a release?

If a set of 'essential' bindings falls behind, do we try to enforce
developer interest? Hold up core svn indefinitely? (After all, if it's
essential, then it *is* core svn, right?) Or do we at some point bite
the bullet and say that it can't be 'essential' if folks aren't
willing/able to keep it up to date?

I guess that's where the 'it's too soon to be having this discussion'
comes in. I definitely see your point that things are going to be a lot
less chaotic, API-wise, after 1.0. So now is too soon to judge whether
folks are willing/able to keep the bindings up to date.

Still it's important to think about the limits of what gets called
essential. Every new 'essential' thing adds a maintenance burden.

-brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 22 20:51:23 2004

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.