Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Eben Eliason]

On Fri, Mar 21, 2008 at 12:11 PM, Gary C Martin <gary at garycmartin.com> wrote:
> Hi James,
>
>
>  > Another thing I remember reading is that if two kids share an activity
>  > and one has an older version of the activity than the other, the older
>  > version gets updated so they both have the newer version.  This
>  > doesn't
>  > seem to be happening.  I have two test machines, one running xubuntu
>  > with the sugar RPMs and another running Suse with sugar-jhbuild.  I
>  > was
>  > hoping to use this alleged ability of Sugar to update activities in my
>  > testing, so I can develop on the xubuntu machine and test on both
>  > without passing USB drives back and forth.  If someone could improve
>  > my
>  > understanding of this I'd be grateful.
>
>  Yea, I'm not aware that this is implemented, just good intentions at
>  this stage (such a great idea and only really possible on an open
>  platform like the XO). Even worse though, as a new activity developer,
>  the first thing I wanted to try once I got my new activity working
>  nicely, was to share it and get some quick feedback – I soon
>  discovered you can only see a shared activity if you already have it
>  installed. So you can only really practically share the blessed
>  selection of activities that you can assume another XO might already
>  have installed, no 'viral' activity distribution model yet.

It's true, at present this is nothing more than a good idea.  It's so
good, however, that I would like to hear some more discussion about
how it might be reasonably accomplished.  The abilities to a)
transparently update to a newer version of an activity you already
have and b) find and download entirely new activities on the mesh by
joining would be fantastic.

Naturally, there are some security concerns, but those could be easily
addressed, I believe, with the usual signing mechanisms.  Updates to
activities would only be transparent if the update was signed, etc.

The bigger question is really determining how to make the whole
transfer process work smoothly in these cases.  Can we use a torrent
model to make it easy to get activities from the mesh, even as people
come and go on an unreliable network?  Can we transfer it directly
from someone who is in the activity we join?  If so, can we still ask
the next activity participant for the remainder if the first one
leaves? As there has been interest expressed in developing basic OS
integrated object transfer as a GSoC project, I wonder if those
efforts could also be applied to this problem, or if this should be
offered as another distinct project alternative.

What do people think?

- Eben