We have two kinds of API abstractions in Subversion: the RA-style
"exposed-vtable" type and the FS-style "hidden-vtable" type. With an
exposed-vtable abstraction, you write things like:
ra_lib->do_diff(baton, ...);
whereas with a hidden-vtable abstraction, you write:
svn_fs_delete(root, ...);
The hidden-vtable style is simpler from the caller's perspective, because there
is only one object (a baton, essentially, although it generally gets a more
descriptive name like "fs" or "stream") to manage, instead of two.
The exposed-vtable abstractions include the RA layer, the editor, and the
reporter. There are also some single-handler "vtables" like delta window
handlers and log receivers which could be converted into hidden-vtable APIs,
athough I suspect that might be more controversial.
The hidden-vtable abstractions we already have include the FS layer and the
svn_stream API.
(I've discussed the RA-vs-FS part of this issue with cmpilato over IRC, so it
isn't just a single developer's crackpot idea. Like all of the 2.0 API issues,
it can be reexamined on the dev list when it comes time to start working on 2.0.)