Since Josh and I (mostly Josh) now have a fully armed and operational
FSFS implementation, we'd like to implement the FSAP abstraction part
of gat's document
(http://www.cdrguys.com/subversion/htmlPluggable/Pluggable3.htm; focus
on Appendix C and ignore types with "_bl_" in the name) so that it can
live in the same executable as the BDB implementation. This means:
* The existing BDB implementation becomes the "baseline" (bl) FSAP.
* The FSFS implementation becomes the "fsfs" (fs) FSAP.
* The three abstract filesystem objects (svn_fs_t, svn_fs_txn_t, and
svn_fs_root_t) have most of their contents removed in favor of
FSAP-specific vtable and private-data fields.
* The libsvn_fs API functions (or at least most of them) change to
do their work through the vtable.
Although it would be possible to implement all of this inside one big
happy library, I'm thinking that three separate libraries (loader,
baseline, FSFS) is probably the right answer. If the loader supports
dynamic linking, then a binary packager can split up the FS back ends
into separate packages so that the main Subversion package doesn't
depend on BDB, just as the Mandrake packages currently do with the RA
layers in order to avoid having the main Subversion package depend on
Apache. I'm willing to be convinced otherwise, though.
One question I'd like to settle:
* Should we have three separate libraries for the loader, baseline
implementation, and FSFS implementation, or should we have one big
happy libsvn_fs directory with "baseline" and "fsfs" subdirs? The
former is more flexible for binary packagers (if the loader has
dynamic linking support, packagers can separate out the FS back
ends into separate packages like some of them do with the RA
implementations); the latter is simpler.
Once that is decided, I'd like to create a new branch (the existing
pluggable-db branch doesn't appear to have any work on it relevant to
the FSAP abstraction) and start working. I'd like license to depart
from gat's document on the following points:
* No infiltration of FSP-level concepts into the three abstract
filesystem objects. Specifically, in svn_fs_t, fsp_name should be
fsap_name, and it should be made clear that the pdata field
belongs to the FSAP, not to the FSP. (I think the latter was
gat's intention, but his comment is unclear.)
* Field names. Sometimes I think he abbreviated too far. fsp_nm
becomes fsp_name, fv becomes vtable, pdata becomes fsap_data.
* Type names. He used svn_fs__ prefixes on private type names. We
only need the svn_fs__ prefix on exported (but private) function
names.
* Constructor functions (fs_vtab_t->{begin_txn/open_txn},
txn_vtab_t->txn_root) should not have pdata arguments, as far as I
can tell. I don't know how the loader would decide what to pass
there, and the implementations should be perfectly capable of
filling in the fsap_pdata field on the returned objects.
Comments? I may forge ahead with this plan without waiting long
enough for feedback, but what is done can be undone, particularly if
it's done on a branch.
(In case anyone is wondering what happened to the "maybe we should
abstract at the DAG layer instead of at the API layer" thread, I think
Josh wound up making enough changes to the tree.c functions that such
an abstraction doesn't really make sense.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 24 22:56:18 2004