Greg,
<understatement>You made my day!</understatement>
Greg Hudson wrote:
>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.
>
Makes sense to me.
>
>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.
>
I was thinking the former, but for no real reason that I can recall. So
I have no real opinion either way.
>
>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.)
>
>
Yes the later was my intention.
> * Field names. Sometimes I think he abbreviated too far. fsp_nm
> becomes fsp_name, fv becomes vtable, pdata becomes fsap_data.
>
>
I'm totally fine with the long names.
> * Type names. He used svn_fs__ prefixes on private type names. We
> only need the svn_fs__ prefix on exported (but private) function
> names.
>
Yup.
>
> * 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.
>
>
Hmm, I thought I had a good reason for pdata arguments. I'll see if I
can dig up my reason. But like you say below, it can be changed if
needed later.
>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.)
>
>
Thanks for taking this on!
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 25 02:42:44 2004