> First I'll say that you might want to avoid keeping a whole file in
memory.
I agree. The current buffer object interface lets me change this later in a way that should not be visible outside the buffer implementation. The in-memory implementation is purely temporary.
> The interface is very flexible. You provide a "family identifier" up
front
> to associate related versions....
Given that in the proposed interface I am passing in the message digest of the base version, does this provide enough information for the store to determine the "family" identity? That is, can the store turn to XDFS, open the base version, and then do some call to learn it's family?
> [Variants on get(...)]
> > get(universal-name) => byte-buffer
> > get-expanded(universal-name) => byte-buffer
> > get-delta(from-universal-name, to-universal-name)
> >
> > I am inclined to suspect that
> > get-delta() is a second order optimization on the wire transfer.
>
> I think the folks using CVSup would disagree. If delta compression is
> second-order, what's first-order?
My naming convention was unclear. It is the intention of the interface that the get(...) call should return the most storage-efficient representation that the server is able to reasonably produce. Typically this will be a delta. The purpose of get-expanded() is to allow the client to decide which version it wishes to use as a baseline.
The get-delta() call allows the client to request that the server perform a "diff" between two specific entities and send exactly that diff.
In hindsight, I think that get-delta() should be renamed get-specific-delta().
shap