9.1 Proposal: Files

[Mel Chua]

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
http://lists.laptop.org/pipermail/devel/2008-October/020692.html 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 (
http://wiki.laptop.org/go/Designs/Journal), 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20081028/21a82474/attachment.html>