On Sat, 09 Jun 2007, David Glasser wrote:
> On 6/8/07, Daniel Rall <dlr@collab.net> wrote:
> >I believe it's just a side-effect of the current RA loader
> >implementation. IIRC, people have looked at changing this a few times
> >in the past, but didn't get any traction. The RA loader isn't a ton
> >of code -- it should be pretty easy to just toss the existing one an
> >re-write it from scratch, if need be.
>
> One problem with this. RA libraries are chosen by two APIs:
> svn_ra_open[2] and svn_ra_get_ra_library. svn_ra_open[2] gets a
> config hash, so it could use the servers file to decide which library
> to use. But the compatibility interface svn_ra_get_ra_library does
> not get it. If a program which uses svn_ra_get_ra_library (using the
> pre-1.2 API) is run against a Subversion client linking both ra_dav
> and ra_serf, I don't see any way for the config files to affect which
> is chosen, so even though your config file might say "use serf!", the
> internal fact that the program you're running uses the pre-1.2 API
> will prevent your configuration from working.
>
> How big of an issue is this? Is it acceptable to implement
> user-configurable RA library support and have it be ignored for
> programs written against the pre-1.2 API? (Note that a user of such a
> program may have no idea what APIs it uses...)
IMO, the value of the configurability outweighs the minor
inconsistency in the API.
Looking at it another way, it's not a whole lot different than adding
a new parameter to a rev'd API, and hard-coding a default value for
the older incarnation of the API. So long as we document the
behavior, I'd say we're okay.
- application/pgp-signature attachment: stored
Received on Mon Jun 11 10:45:30 2007