On 10/04/2007 15.39, John Peacock wrote:
>> Subversion already has a low-level API: the C API. Reinventing a
>> still-low-level-but-not-identical C API with SWIG is not a good idea,
>> but it would be a better idea if it were easier to achieve: and I mean
>> easier for both SVN developers (maintaining the bindings), and binding
>> users (which are let down by the complexities of building the SWIG
>> bindings and SVN itself just to drive a commit by script... eg. for
>> years we haven't had a Python 2.4 binding for Windows just because
>> *nobody* was able to correctly compile it).
> I agree that the C API would be the obvious target for the low level
> bindings, with as little abstraction as required to make the bindings
> "native" for the language involved (i.e. creating a native object that
> would be the equivalent of the context pointer).
OK, then we agree.
For Python, SWIG most definitely is not the best way to achieve this. Thus, I
hope you don't oppose if the low-level bindings for Python are moved to
Python, totally dropping SWIG support. If Perl bindings are more successful in
using SWIG, that's fine: I guess Perl/Ruby developers will just maintain those
> But I'm leery of
> having native higher-level abstraction API's for each language
> individually. The more that the higher level API's diverge, the less
> crossover development will be possible, which will again lead to the
> less supported languages within the core developers getting less TLC...
I think that providing low-level bindings for scripting languages is a
reasonable goal for the Subversion project. As for the higher-level bindings,
I guess that developers of each community will probably come up with their own
libraries or designs on the top of the official low-level bindings. For
instance, for Python there's already pysvn; I think variety is good, since
there is not a clear winner here.
IMHO, whether or not the Subversion project should officially back up one
unified high-level API is immaterial to this thread. I think it might
eventually be a good idea, once there's been enough experience and development
with several high-level APIs maintained as third-party contributions.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Apr 10 16:23:26 2007