Re: Plugin mechanism(s) for Git?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 15 Jul 2016 16:18:28 +0000 (UTC)
Ben Peart <peartben@xxxxxxxxx> wrote:

> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]