I'm going to try to reword this as a list of features that would potentially be good for the XO to have, followed with a section on how Sugar currently addresses the problem, and then potential solutions, including - but not limited to - "modifying the datastore to provide human-readable file names on disk," as Ben Schwartz has rephrased "use filesystems."  I'm doing this because I think that Erik points out some good problems to tackle in his email, and I'd like to take a moment to explore the range of possible solutions instead of framing this solely as a Filesystem Vs No-Filesystem argument. (This discussion may eventually make more sense on a wiki page.) The original email is at <a href="http://lists.laptop.org/pipermail/devel/2008-October/020692.html">http://lists.laptop.org/pipermail/devel/2008-October/020692.html</a> for reference. -Mel PS: Metaquestion - is this a helpful way of looking at things? I did this as an experiment, with much help from bemasc and Jerub over IRC, and would like to know if this actually advances the discussion. ----------------- begin reply! ---------------- 1) Compatibility with existing applications Feature: Making it possible to convert Linux/X applications into Activity bundles, retaining all important functionality, without source code alterations. Current Sugar: Has a custom API for saving data that's "difficult to work with" (help clarifying, please - why is this hard?) Potential solutions: I've heard "using a standard filesystem," "Pippy does part of this already," and others... please discuss. 2) Data access and user-perceived reliability: Feature: Encourage users to add appropriate metadata (such as titles) to objects they want to save by requiring them to explicitly decline to do so. Current Sugar: Tries to do this already in practice and in future design in a number of ways - users can explicitly name and save (keep) items in their Journal, there are Journal design documents that detail separate views for looking at a history of user actions vs. finding files (<a href="http://wiki.laptop.org/go/Designs/Journal">http://wiki.laptop.org/go/Designs/Journal</a>), etc. - how can we better articular the desired feature here, using words more concrete than "it should be easier"? Potential solutions: Ben broke it down into complaint/solution: "The complaint is that users can't find things because they're not providing enough metadata for search to work, and there's too much stuff for them to find it without search. The solution is to encourage users to provide better metadata, and reduce the number of unwanted objects that are produced." Stephen suggested that the Journal capture metadata on how long a given Activity was open as another metric to sort by. Erik's original email suggested using a standard filesystem and requiring users to manually save things with unique names (rather than autosaving). Others? 3) Resting on upstream stability: Feature: It should be possible for upstream contributors to see, at any given point in time, how features on, code in, and bugs filed against the XO trace back to the applicable things that they can fix in the standard version of their upstream project. Current Sugar: Actually, I don't know how this works at all. Have there been problems getting needed help from upstream? Why? Potential solutions: Use the standard versions of upstream projects without modification. Others? 4) Collaboration Feature: Provide a standard mechanism for Activity collaboration between an XO and another computer not running Sugar. Current Sugar: Install Sugar on the other computer and use Jabber to collaborate. (Time-consuming, and not always possible given time and privilege constraints on the non-Sugar computer.) Potential solutions: Use standard non-Sugar-to-non-Sugar computer collaboration systems, including thoes based on file-based asynchronous collaboration. Make cross-platform non-Sugar versions of Sugar Activities (and a script to autogenerate these from native-Sugar Activities) that can somehow collaborate seamlessly with XOs. Others? 5) Hackability Feature: Indicate how an Activity's functionality and the objects it creates in the Journal map to editable source code files on the XO. This indication should be shown directly in the Sugar GUI for an Activity and also when a user is viewing source code for that Activity. (This can probably be phrased much more coherently. Help?) Current Sugar: There are currently two "views" that coders have to switch between; the underlying filesystem with .py files in nested and named folders, and the Journal view for the same Activity, which does not (afaik) expose a way to get into the source code through the GUI. (Exception: if you hit the "view source" key for Chat, one file of the Chat code opens in Pippy and is editable. Even for this, though, if you want to edit other Chat files, you have to navigate the filesystem.) Potential solutions: Have them be the same view. Others? 6) System modularity Feature: Code modules and applications that save objects should be decoupled from code modules and applications used to search and index objects. Current Sugar: I do not know enough about the architecture to say much here - others? Potential solutions: Same as above.