On Tue, Mar 25, 2008 at 11:44 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > > Delta-based storage is an implementation detail, certainly possible (I > > provided cites in the olpcfs page for how it would be done). I don't > > think it should be a visible part of the API. > > Of course it is an implementation detail, but one that is a major > roadblock in the effort to implement the specified design.
The olpcfs design envisions a user-space process to do garbage collection of old versions; it's not hard to do delta-compression in userspace. xdelta and bsdiff do a fine job. To transparently uncompress when the old version is accessed is only a little more difficult, you just link to libxdelta2. > > > - get a saner way of passing files from activity side to the > DS-managed side, > > > > My answer here: they are just files. All existing applications can > > open files, given a path. > > I was talking here about the other way, checking in files into the DS: > during a Write session, what needs to do the activity in order to get > a new version every time after the user clicks on the Keep button? > Just close the file and open it again? Yes. > In most cases, every time an activity saves the current state several > files plus their metadata will be updated, can that happen atomically? Well, it's certainly *possible* in the current implementation, but I'm wary of promising too much. POSIX generally doesn't provide multi-file atomic update. Amino (http://www.fsl.cs.sunysb.edu/docs/amino-phdthesis/amino.ps) extended ACID transactions to POSIX-land via some heuristics (treat all operations by this application as atomic, etc), but I'm not convinced yet that this is necessary. Can you provide some specific use examples? --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
