-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mel Chua wrote: > I'm going to try to reword this as a list of features that would potentially > be good for the XO to have
Me too. I should make my bias clear: I believe we should put our efforts into improving our existing datastore/Journal implementations, focusing on pure-userspace solutions with carefully considered semantics, robustness, and performance properties. I have yet to be convinced that any filesystem-like proposal can provide the behaviors that I believe we require. If we give up on these behaviors, then there is hardly any reason left to develop Sugar, and we should instead just ship a standard lightweight desktop. > 1) Compatibility with existing applications Problem: In current Sugar, Linux/X applications that are ported without source-level changes cannot retrieve and store data to the Journal. Erik's solution: Throw out the current datastore and API, and replace it with a straight POSIX filesystem. Remove the Rainbow layer that prevents Activities from accessing files to which access has not been granted explicitly by the user. Other solutions: - Throw out the current API and replace it with an API implementing similar semantics but routed through the VFS layer instead of DBUS. - Write a userspace wrapper that copies files out of the datastore using the current API to an appropriate location, and then copies the modified files back into the datastore when the file is updated (e.g. using inotify). - Replace the GTK filechooser with a Datastore-aware chooser (e.g. http://wiki.laptop.org/go/Journal%2C_reloaded) > 2) Data access and user-perceived reliability: Problem: 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. Erik's solution: Only keep objects by saving them as files. This forces users either to choose a unique name for each item they produce or to close an Activity instance without producing a file. Unique names provide searchable metadata that may improve the effectiveness of search, and requiring users to type in a unique name in order to save may reduce the number of objects that are saved, allowing easier non-search navigation. Other solutions: - Use modal dialogs to encourage users to provide better metadata such as titles. (We may then easily experiment with making titles optional or mandatory.) - Reduce the number of unwanted objects that accumulate - by providing a "draft mode" option that does not produce any object - but still produces a listing in a separate Actions view (see http://wiki.laptop.org/go/Designs/Journal) - by resuming previous instances by default, so as to encourage continued work on existing objects - by automatically "starring" only those objects that have been titled - and automatically deleting the oldest unstarred objects when necessary to free space or declutter the Journal - and emphasizing or only showing starred objects in the default view of the Journal > 3) Resting on upstream stability: Problem: Our current datastore is buggy. Erik's solution: Replace the datastore with a standard Linux filesystem that already has millions of users and is maintained by upstream developers. Other solutions: - Write a dramatically simplified datastore that is less likely to have serious bugs. - Join with Gnome and other projects to produce an upstream datastore that serves our needs, is maintained independently, and has many stakeholders. - Devote more OLPC developer time to the datastore. > 4) Collaboration Problem: Users can't send Objects to each other directly over the network. Erik's solution: store Objects directly in a Linux filesystem, and then use a standard file-sharing mechanism such as an HTTP server to list these files, possibly with some access restrictions. Other solutions: - Use Scott's HTTP-based networked object sharing system that runs over Xapian and the datastore - Implement the push-to-share plan drawn up at http://wiki.laptop.org/go/Specifications/Object_Transfers > 5) Hackability Problem: A sophisticated Journal-like interface abstracts away the behaviors of the underlying filesystem. This means that using the interface does not provide children with knowledge required to understand and alter its implementation. Erik's solution: Provide a direct view into the underlying filesystem as a first-class component of the interface. In this way, children will gain familiarity with POSIX filesystem semantics and so be better prepared to modify Sugar. Other solutions: - Extend the Journal so that it is easy to write Activities without touching the filesystem. - Accept the two systems as a necessary cost in order to provide a richer user experience. - Regard the filesystem as a low-level implementation detail, as we regard a raw block device. > 6) System modularity Problem: The datastore is a linchpin of the system. If it fails, the system stops working. If its API is changed, then potentially all Activities and many other system components must be updated to the new API. Erik's solution: Make Activities use the standard POSIX filesystem API instead, placing their files directly into the user's filesystem. Drop any datastore functionality that cannot be expressed through this API. Other solutions: - Accept the datastore as one linchpin among many. - Improve the datastore design for better robustness - Provide an API wrapper using FUSE or inotify so that Activities may store data into the datastore while being aware only of the POSIX filesystem API. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkH8uAACgkQUJT6e6HFtqRmLgCbBAOg0SstRiHbW82YI/n0KSe/ g7YAn0abgz0ter8fcVpuX7KJ8CzHI0DW =tfFW -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
