Konstantin Khomoutov <kostix+git@xxxxxxxxx> wrote: > Ben Peart <peartben@xxxxxxxxx> 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... -- 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