Re: Plugin mechanism(s) for Git?

From: Eric Wong <e@80x24.org>
To: Konstantin Khomoutov <kostix+git@007spb.ru>,
	Ben Peart <peartben@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Jeff King" <peff@peff.net>,
	"Nguyen Thai Ngoc Duy" <pclouds@gmail.com>,
	"Michael Haggerty" <mhagger@alum.mit.edu>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"David Turner" <novalis@novalis.org>,
	"Joey Hess" <joey@kitenet.net>,
	"Ronnie Sahlberg" <rsahlberg@google.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: Plugin mechanism(s) for Git?
Date: Fri, 15 Jul 2016 21:28:43 +0000	[thread overview]
Message-ID: <20160715212843.GA5131@dcvr.yhbt.net> (raw)
In-Reply-To: <20160715194752.f10351ae84346bd533495496@domain007.com>

Konstantin Khomoutov <kostix+git@007spb.ru> wrote:
> Ben Peart <peartben@gmail.com> wrote:
> > > 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...