On Sun, Mar 23, 2008 at 12:20 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > - Do you think that the POSIX API is very much tied to the underlying > implementation or should be discussed separately?
I have at least three different implementation ideas. I plan to use FUSE for the "crappy first draft" implementation; it may turn out that the crappy first draft is actually good enough for real use, but there are certainly lots of other alernatives, both for flash and for disk-based filesystems. Martin seems to be arguing for using git under the covers; that's a fine implementation. > - This POSIX API would be the main way to access the data? Or just one > more way? If so, have you already thought about the main API? Anything > better than D-Bus? The POSIX API should be the main way to access the data. Complex compound queries may be more efficient if they use a special-purpose API, and there might be special hooks for the garbage-collector and maybe import/export tools, but fundamentally data store objects should be "just" files. > In general, I would like to know first more details about your > motivations for redesigning the DS. I outlined these at the top of the olpcfs wiki page. > Mine are the following: > - add versioned entries and delta-based storage, 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. Versioning is definitely a motivation; the Journal might add extra versioning metadata to account for non-local versions; I'll try to find time to write that up more explicitly. > - 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. > - make it more maintainable, perhaps add one lawyer of abstraction so > we can switch later to a different full text engine, metadata storage, > etc, The proposed "olpcfs" is exactly the "layer of abstraction". Lots of different implementations under the hood of the proposed API are possible. > - increase scalability and raw performance. Not sure exactly what you mean here, but these seem to be implementation issues, not API issues. Unless you think that some of the proposed APIs are impossible to implement efficiently? Our existing Sugar activities don't heavily exercise the filesystem, so I think that raw performance is not an important metric for our first implementations. I'm much more concerned with the transparency and interoperability of the API. --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel