On Wed, Nov 29, 2000 at 12:53:34PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>
> > Versioning an ABI is cake; this aspect doesn't bother me at all. Using a
> > registration process is the most effective way to do so.
> >
>
> +1. Actually, Greg -- remember how you and I discussed this last
> summer?
My mind hasn't gone to mush. Yet. :-)
> The now defunct "libsvn_svr" library had a whole plug-in
> architecture that solved this problem. Time to go look in the
> attic. :)
Well, it is probably easier to simply describe the process rather than try
to extract it from the code and replicate it.
1) svn client loads an RA DSO
2) look up a symbol named svn_ra_FOO_init
3) call that function with two parameters:
svn_error * svn_ra_FOO_init(int abi_version, struct whatever *params)
4) the function will call back into SVN to register various items
Using the callback scheme allows for looser coupling of the ABI. If a
registration function needs to change prototypes, then you can simply
introduce a new function with the extra change:
void reg_func(int param1);
void reg_func_2(int param1, char *param2);
Old modules call the former, new modules call the latter. Everybody is
happen.
You can then define abi_version however you'd like. Maybe it just refers to
the type of the "params" init parameter. Maybe it refers to the whole API
exported by SVN to the RA modules. Maybe it has a "major" version component
whereby changes in that completely invalidate old modules, along with a
"minor" component that signifies old modules will work, but there are new
features they could take advantage of (and make this determination based on
the minor vsn).
Personally, I like saying "bump the version on each release; any change in
that number implies an incompatible ABI." If you don't take that stance,
then you need to track all of the APIs (not just the "init" API, but also
things like svn_error_* functions, svn_string stuff, etc).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006