[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: RA API changes

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-01-11 20:19:04 CET

On Mon, 10 Jan 2005, [UTF-8] Branko ─^Libej wrote:

> Peter N. Lundblad wrote:
> >So, if no one objects, I'd like to deprecate the whole svn_ra_plugin_t and
> >provide a new fresh struct. Also, I'd like to resolve a part of issue
> >#1931, by converting the API to a FS-like interface, so we don't expose
> >the vtable to the user anymore. This will keep the wrappers inside
> >libsvn_ra and make future deprecations easier.
> >
OK, I have another question here. In ra_svn.h, we expose the way libsvn_ra
initializes the three currently existing libraries. We have declarations
for public functions: svn_ra_dav_init, svn_ra_local_init and
svn_ra_svn_init. There is the requirement that libsvn_ra_foo exports
svn_ra_foo_init. Are these to be seen as public API:s? The problem is that
I am creating a completely new vtable which isn't part of svn_ra.h. Could
I just remove these declarations (moving them to ra_loader.c in
libsvn_ra)? I and maxb discussed this somewhat on IRC and we aggreed that
a user of libsvn_ra shouldn't call these directly, but instead go via

Also, I'd like to move the URL shceme to ra_lib mapping into libsvn_ra, so
we don't have to load all the three ra libraries just to check what URL
schemes they support. If someone is going to support 3rd party RA
libraries in the future, this has to be undone. Is anyone objecting to
this change? Anyone working on 3rd party RA library support?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 11 20:20:21 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.