The XO laptop gets a Windows makeover

[Erik Garrison]

On Sun, Oct 26, 2008 at 9:50 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
> On 27.10.2008 00:57, rihoward1 at gmail.com wrote:
>
>> On Oct 26, 2008, at 4:09 PM, Albert Cahalan wrote:
>>
>> Means of file sharing can be setup fairly easily in Sugar if you want
>> to move raw files around. Currently file sharing is performed through
>> activity sharing.
>>
>
> Does "setup fairly easily" mean someone has to write a program
> ("activity") to do it? If yes, it's not easy (yet). Will it work with
> arbitrary binary files?

We can do asynchronous file-based collaboration intelligently.

I am currently thinking about a very simple solution which can be
hooked into Sugar to allow users to view each other's files provided
they are both on the same network (mesh, router, wired net, etc.).

The mechanism I am considering will work as follows:
 1) User clicks on another XO icon in the Neighborhood view.
 2) Browse is opened and pointed at a specific port on the IP of the XO.
 3) A web browser on the 'host' XO sends a directory listing of the
user's share/home/journal folder to the 'client'.
 4) The client user can download whatever file they wish to share.
 5) The client then opens the file in a suitable application.

To satisfy privacy concerns, we could provide three configuration
options to users:
 - Share all: share the entire user's home directory tree.
 - Share only: share only files and symlinks explicitly added to a
'share' directory.  These copies or links could be enabled using a
menu option in whatever data browser runs on the system.
 - Share nothing: don't run the webserver.

Such a scheme would simultaneously open the collaborative
possibilities offered by the mesh and cut the gordion knot of
collaboration systems and APIs, allowing any computer with a web
browser to enter the collaborative arena!  This scheme would make it
easy to collaborate asynchronously between Sugar and non-Sugar
environments.

To implement this it would be sufficient to provide a web interface to
the journal.  I believe a modular, file-based solution would be
preferable from a programming and maintenance perspective, but the
opaque nature of the filesystem from the users' perspective stands in
the way.  I am hoping that in 9.1 we provide users the capability to
save files to their home directory by giving their activity instances
names.  (Perhaps we could autosave everything else, but delete it
after some time period of non-use.)  This would make it possible to
provide collaboration by setting the webserver to provide a directory
listing of the user's home instead of writing a specialized interface
to the journal.  This would make it much easier to find and extend
existing upstream systems which do the job well to meet the specific
needs of the XO.

I am also hoping that it will be easy for users to run applications on
files obtained from non-local, non-journal/datastore sources.
Currently doing so is impossible from the Sugar GUI.

A third hope is that our security model can be relaxed to allow the
launching of an application against a file downloaded via a web
browser.  This would eliminate a step (back into the journal or file
browser) to open a file from a remote source.

Erik