RFC: RA API changes

["Peter N. Lundblad" <pe...@famlundblad.se>]

Hi,

ON trunk, we have deprecated one svn_ra_plugin_t member (get_log). On the
locking branch, we have one more deprecated (get_commit_editor). And ...
guess what, In my current WC, we depreate four more members, the ones
taking an svn_ra_reporter_t.

Currently, we don't deprecate the whole struct, since we can just add new
members to the end. This is because we don't support loading external RA
modules (yet).

A problem is that each RA module needs its own compatibility wrapper for
each function. They are trivial, but it is a lot of cut-n-paste:-( And it
is also messy.

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.

I don't think this is controversial, but it involves changing code in many
places in the client, so I ask first:-)

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: RA API changes

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2005-01-11 at 14:19, Peter N. Lundblad wrote:
> 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?

Practically speaking, no, I don't think we have to worry about those
being considered part of our public API.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: RA API changes

["Peter N. Lundblad" <pe...@famlundblad.se>]

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
svn_ra_get_ra_library?

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?

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: RA API changes

["Peter N. Lundblad" <pe...@famlundblad.se>]

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.
> >
> >I don't think this is controversial, but it involves changing code in many
> >places in the client, so I ask first:-)
> >
> >
> Fine, but *don't* do it on the locking branch, do it on trunk (if you
> can) or on a separate branch, and don't forget the boars; er, bindings.
>
Yes, I'll do in on trunk so others can extend the RA API if necessary
before merging locking. The bindings? They will use the current
compatibility API until someone else updates them, I'm afraid. I'm not
going to do that.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: RA API changes

[Branko Čibej <br...@xbc.nu>]

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.
>
>I don't think this is controversial, but it involves changing code in many
>places in the client, so I ask first:-)
>  
>
Fine, but *don't* do it on the locking branch, do it on trunk (if you 
can) or on a separate branch, and don't forget the boars; er, bindings.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org