Opened 6 years ago

Last modified 4 years ago

#8171 new enhancement

Possible XO to XO object transfer mechanisms for sharing data

Reported by: sj Owned by: Eben
Priority: high Milestone: 10.1.1
Component: sugar Version: 1.0 Software Build 802
Keywords: Cc: tomeu, marcopg, wad, martin.langhoff, mikus@…
Blocked By: Blocking: #6932
Deployments affected: Action Needed: finalize
Verified: no

Description

: Teachers always want to share files. They tend to learn how to use USB keys to share things, which takes many extra steps. Eric Burns' proposal for publication and journal sharing was a way around this, and he got some feedback from Tomeu; we should encourage this (and documenting its implementation) actively.

Two issues come to mind : setting the interface for file-sending (and embedding it in Sugar), and determining how it works. Requests were for both a fire-and-forget transfer that is more like localmail of an attachment, and for oen that is more like a synchronous shared activity where you see the person you are sending it to.

Change History (8)

comment:1 Changed 6 years ago by sj

  • Blocking 6932 added

comment:2 Changed 6 years ago by kimquirk

  • Milestone changed from Not Triaged to 9.1.0
  • Type changed from defect to enhancement

comment:3 Changed 6 years ago by Eben

  • Action Needed changed from never set to communicate
  • Cc marcopg wad martin.langhoff added
  • Component changed from not assigned to sugar
  • Priority changed from normal to high
  • Summary changed from Classroom feedback: Need to share a file from one XO to another to Possible XO to XO object transfer mechanisms for sharing data

There are a few ways we can think about transferring files:

  1. Synchronous:

This is the most straightforward, the most direct, and the first option we should provide. The action is quite direct, and involves selecting the person to send something to, and what to send eg. "Send <this object> to <my friend>." The transfer is synchronous, and depends on network connectivity. Ideally, our transfer system will also include a recovery system by which interrupted transfers can be resumed.

  1. Asynchronous, server:

The next obvious method of transferring files is in the form of email attachments. More generally, we depend on a server to hold the file and later make it accessible to the other person. This solution can time shift the transfer, and also help to get around firewalls. It doesn't, strictly speaking, depend on email, but it could.

The real question is if we want to implement, in the background, a transparent system for the recipient which provides this service (and shows alerts, handles the downloads, etc. automatically). If not, do we still create a service for the sender which wraps the file into an attachment and sends it off to another? This depends on mapping our notion of identity to an email address, of course, which can complicate things some. I like the idea of an OS provided, transparent, asynchronous message/object passing system, though.

  1. Asynchronous, messenger: We could also implement an asynchronous message passing system which depends on no server at all. Otherwise known as the 'briefcase idea', it involves wrapping a message up into an encrypted bundle and then passing that bundle to a) peers and/or b) the school server for future delivery to the intended recipient. Of course, this uses space on the messengers system while in transit, instead of the server, so it would have to be opt in.

In other words, one XO might send out a message to others asking "does anyone here know of <buddy X>". They could then reply with information such as the number of times they have seen <buddy X>, the last time they saw <buddy X>, and/or the frequency with which they have seen <buddy X> (in a period of a week, perhaps). Then, the first XO could request to one or more of the respondents that seem to see <buddy X> reliably enough to carry this message. They would get a "messenger invitation", which they could accept or decline, and then the next time they see <buddy X>, they would send him an invitation to accept the message, and then remove it from their machine once sent (or declined). Naturally, the school server could also offer (and automatically agree) to store the message as well, eliminating the burden on kids.

This system could also provide a way, for instance, for brother Bob to ask sister Alice to turn in his homework to his teacher while he's out sick. There are lots of other reasons that make this a compelling idea.

comment:4 Changed 6 years ago by martin.langhoff

  1. Asynchronous, server:

xs-0.5 (in development) implements a custom Moodle on the XS, which has many options for this. It is webbased, which is not what you are describing, but it's really good for the task at hand -- sharing course materials.

comment:5 Changed 6 years ago by Eben

Well, presumably anything web based can be OS-integrated through the use of some proper GET/POST magic. I'm not sure the best way to tackle the problem in light of the desire to have Sugar run on many platforms, and also for people without a school server.

What are your thoughts on the best ways to make such a system, tied into the OS/Journal itself, functional in all scenarios? For instance, I think Google was happy to provide accounts to all of our kids. Can we link each kid to an account, and automatically send emails from that account (when initiating a transfer), or check that account for incoming transfers (with some key that identifies them as such), so that we can pull them down and display an alert when they arrive automatically? One reason I like this approach is that it might be possible to hook it up to a variety of email systems; and if not, anyone can setup a gmail account on their own as well.

comment:6 Changed 6 years ago by mikus

  • Cc mikus@… added
  • spec_reviewed set to 0
  • spec_stage set to unknown

comment:7 Changed 4 years ago by garycmartin

Just a FYI to update this old ticket. In Sugar since 0.84 the Journal has supported a synchronous Send to --> Friend feature for any Journal entry. Only requirement is that the activity entry needs a MIME type set (file a SL bug ticket if you have a favourite activity that you want to share entries from and is missing a MIME type). It was first implemented (by Tomeu) with only direct network support machine 1 --> local network --> machine 2, a second iteration added support for machine 1 --> Jabber server --> machine 2 so sharing also works across the Internet if you can both connect to a public Jabber server. I can't remember if the Jaber server feature arrived later in Sugar 0.86, or if it made it in time for Sugar 0.84. Great feature, use it quite a bit both locally between XOs and to remote users over the Internet.

comment:8 Changed 4 years ago by Quozl

  • Action Needed changed from communicate to finalize
  • Milestone changed from 9.1.0-cancelled to 10.1.1
  • Version changed from not specified to 1.0 Software Build 802

Tested XO-1.5 build os302. Send-to feature is working well for XO to XO journal entry transfer. Result is depending on MIME type.

ObjectResult
Photo taken by RecordOpoens in Image Viewer and displays well
Program written by PippyOpens in Write (not Pippy) and displays well
Photo collection created by RecordOpens in Browse and displays as XML
Log created by TerminalDoes not transfer
Timings created by StopwatchOpens in Write and displays badly (a data packing format)

I think this ticket can be closed, and any activity specific misbehaviours can be logged separately. Could I please have a seconder?

Note: See TracTickets for help on using tickets.