Re: Plugin mechanism(s) for Git?
- From
- Konstantin Khomoutov <kostix+git@007spb.ru>
- Date
- Jul 15, 2016, 16:47 UTC
- Message-ID
- <20160715194752.f10351ae84346bd533495496@domain007.com>
- In-Reply-To
- <loom.20160715T181543-821@post.gmane.org>
On Fri, 15 Jul 2016 16:18:28 +0000 (UTC) Ben Peart <peartben@gmail.com> wrote:
Show 22 quoted lines
> > Thanks for this great summary of the problem, Christian! > > > > I think a generic plugin mechanism would be great but how would we > > do it? > > I’m also very glad to see the discussion about coming up with a good > pattern for how git can interact with external code. I had also > noticed all the in-flight topics as I was searching for a good > pattern to adopt. > > > > > 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.
Using dynamically loaded libraries precludes or greatly complicates creation of plugins written in languages different from C (or C++ FWIW).
So that could be okay for some type of plugins (let's call them "core") but not really for third-party / inhouse implementations.