On Sun, Oct 26, 2008 at 9:50 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
>
> On 27.10.2008 00:57, [EMAIL PROTECTED] 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
