Re: Plugin mechanism(s) for Git?

Konstantin Khomoutov [off-list ref] wrote:

Ben Peart [off-list ref] wrote:

quoted

quoted

Lars Schneider wrote:

We could dynamically load libraries but this would force us to
freeze the ABI as mentioned by Duy:
http://article.gmane.org/gmane.comp.version-control.git/298463

I wouldn’t be too quick to dismiss dynamically loaded libraries as
there are some distinct advantages over the other patterns especially
performance and simplicity.  I realize it requires us to version the
ABI but there are established patterns to manage this.  It also isn’t
that much different than us having to freeze or version the protocol
for communicating with a remote-helper.

(re-adding dropped CCs)

The critical difference is protocols can be tested and debugged
in a language/tool-independent way.

Using dynamically loaded libraries precludes or greatly complicates
creation of plugins written in languages different from C (or C++ FWIW).

Agreed, and folks working on language bindings are often not
experts in or comfortable working in C (I speak for myself,
at least).

It's probably not a good use of git core developers time to
learn to deal with bindings and quirks for language XYZ, either
(as language XYZ likely breaks compatibility more than C,
POSIX or the git data model).

The SVN Perl XS bindings we use for git-svn have introduced
numerous incompatibilities and bugs over the years we've had to
deal with.  I doubt Perl bindings are a high priority for SVN
developers; and even checking their API headers reveals a huge
number of deprecated functions in their native C API.  I'm not
sure if it's a lack of foresight on their part or what, but I'm
happy git's data model and command-line interface has barely had
to deprecate or break compatibility in over a decade.

Protocols like "cat-file --batch" and fast-import using
pipes is great and I hope they're portable enough.  I would
welcome additions to avoid process spawning costs for things
like update-ref/rev-parse/etc...