--On Saturday, February 21, 2004 1:12 AM -0600 "C. Michael Pilato"
<cmpilato@collab.net> wrote:
> The only way I can advocate keeping the bindings joined with the main
> Subversion product is if the community can agree that the bindings are
> first-class citizens -- that we spend time catching the bindings up to
> the completeness level of their C counterparts, create a regression
> test framework, and thereafter treat bindings bugs just as seriously
> as core library bugs.
I have never argued that it should be treated anything different than that!
Ideally, all the same rules that apply to 'core' should apply to the bindings.
However, there's been a willingness to assign 'ownership' to the bindings. I
think that's been detrimental to the health of the bindings and that's led to
this current discussion of throwing them out.
I think we (as a community) have done an extremely poor job of integrating the
bindings into our community. There is this 'us' vs. 'them' mentality that I
think isn't helpful in this conversation. As an example, we've allowed the
bindings to have separate build systems. I've tried to help address this by
ensuring that all of the bindings are buildable in a unified build system (at
one time or another). So, yah, a lot of my focus has been on getting the
bindings to work and be integrated as I think they are integral part of
Subversion.
> But for me the line you're looking for involves essential-ness. If we
> as a community say that the bindings are an essential piece of
> Subversion, then we must start treating them as such (and can keep
> them in this project). Otherwise, get 'em out.
I think they are essential. Let me explain:
Without the bindings being distributed as part of the 'core', we have a much
higher barrier of entry for extensibility; I think it's very good when we can
tell people that by having downloaded the 'core' Subversion, they also have
the ability to extend Subversion with their favorite language and start
playing with it *right now*. Only distributing a C API and command-line
interface takes away from that aspect. At the talks that I've given, our
bindings are a *huge* selling point to a lot of real-world developers.
To the question that was raised earlier today on the mailing list: what are we
shipping? A command-line client or a library? Every time, I'm going to say a
library. And, providing as many language bindings as possible strengthens
that claim. Subversion isn't about the CLI we ship; it's about the libraries
behind that CLI. And, we should ensure that as a 'core' community, we ensure
those libraries work on all of the languages we can.
Realize that many people I work with spend their days extending SCM systems.
They like the fact that Subversion comes with these bindings by default - this
is in contrast to almost every other SCM out there. Having to force their
users to download *other* things and build those probably isn't going to be
welcomed. But, with Subversion, it's all there. It's hard enough to convince
people to integrate software, but by removing the bindings *after* 1.0 but
before 1.1, it's harder to convince people it's worth the effort to integrate
Subversion into their products. We should be focused on lowering barriers,
not increasing them.
>From a developer's perspective, by having them integrated, it's easier to see
when things break; whenever I build, I *always* build the Python bindings; to
me, yes, they are a *first-class* entity. I've maintained that from the
beginning - I think by expecting them to be first-class, they will become
first-class eventually. However, people seem to have been willing to cut the
bindings too much slack. Yes, we need more regression tests; but we need lots
of them everywhere else, too.
However, the bindings have always been on a time-delay curve with respect to
the rest of the code: deservedly so, they only reflect our API and they are
only now getting more attention as people use them and our API changes
dwindle! I actually expected our immediate post-1.0 timeframe to focus on
getting the bindings solid and up-to-par with the rest of the system
(regression tests, etc.). While our API is frozen (following our versioning
rules) and we get feedback from more people trying to use Subversion as a
platform for writing their own apps, I thought we'd get more feedback with
respect to the bindings. Yet, at some point, I'd expect the maintenance of
the bindings to be as low-volume as the rest of the core code. We're just not
there yet though as the bindings aren't as well-tested and deployed; but, when
the bindings aren't chasing a moving target, I think it'd slow down eventually.
So, yes, I think the bindings are essential, and I think more harm than good
would be done by exiling them.
I'll be very saddened to see them leave the core Subversion community, as I
think they are one of the strongest selling points we had. *sigh* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 21 09:33:35 2004