[sugar] activity sharing protocol

[Marco Pesenti Gritti]

On Mon, 2007-02-19 at 14:40 +0100, Marco Pesenti Gritti wrote:
> On Sat, 2007-02-17 at 17:53 +0000, Dafydd Harries wrote:
> > Dan Williams is over in Cambridge (UK) this week, visting the Collabora office
> > to discuss how activity sharing will work. We've been looking at the
> > Python/D-Bus interfaces that activity developers will use to communicate with
> > other participants, but mainly at how things will work at the network level.
> > 
> > I've tried to capture what we've covered in the past couple of days, and I've
> > put the resulting notes up on the wiki:
> > 
> > http://wiki.laptop.org/go/Activity_Sharing
> > 
> 
> Thanks for putting this together! Just some thoughts:
> 
> > is known to work in resource-limited environments
> 
> Just a curiosity, in which environments have it been used?
> 
> > Activities working with a server, ~30 participants in the activity,
> ~100 contacts on the server.
> 
> 100 contacts seem too limited, or at least out of proportion with 30 per
> activity. Maybe a more realistic proportion is 1/10.
> 
> > Can't use non-free JVM if Java
> 
> Even assuming free JVM, is it worth to have a JVM installed/running for
> just this?
> 
> >Question: if an activity exists but is not anyone's "current" activity
> >(i.e., all buddies switched to a different activity but still have the
> >inactive one running in the background), does the PS care about that
> >activity at all?
> 
> Totally. It should be still visible on the mesh view. Also there might
> be cases of activities which could be evolving and exchanging data even
> without active user participation.
> 
> >For bandwidth and scalability reasons, the PS will have to filter or
> >not subscribe to some presence information for buddies. It needs to
> >figure out which buddies and which activities are more relevant to
> >Sugar and only deal with those.
> 
> Can you elaborate about this please. Is it just an implementation
> details or it effectively limit the information we will be able to
> retrieve about a buddy.
> 
> >one-to-one channels like an IM or a voice/video call can be made into a
> >private activity
> 
> I think activities are inherently social. There might be cases where
> private can be used but it's gen2 stuff IHMO.
> 
> >do we need to migrate activites from the mesh to the server, and if so,
> >how do we do it?
> 
> I think this is an important use case. Kids could start activities at
> home, in a small group, and then continue it at school, with other
> buddies joining it.
> 
> >are participants in an activity equal, or is there one person who is
> >hosting each activity? 
> 
> I don't think there is one true strategy for this. I see it as activity
> dependent.
> 
> >what does the Sugar API look like?
> 
> That's a very important question and one that we should figure out
> early. I'd like to see at least a very general proposal about it. A
> starting point could be the current presence service and the plan I and
> Dan discussed. But it's unclear, for example, how the tubes will
> integrate with it.
> 
> >If you're sitting next to someone and want to make them your friend,
> >but you're both on different mesh RF channels, you won't see them on
> >the link-local.
> 
> I'm unclear on how the network structure relates to the UI here. What I
> was thinking is that you would just see the friend in the mesh view,
> even if he is not on your local link.
> 
> > How do we implement searching for people as described in the HIG?
> 
> What issues are you seeing with this one? It could just be a search in
> the presence service model (unless we want to avoid to fetch part of the
> info about buddies).
> 
> > Implementation plan
> 
> I think it's difficult to discuss this before having an idea of what the
> API will look like. There is code based on the existing presence service
> and we need to figure out a migration plan.

I forgot an important question. Will all the communication have to go
through tubes or we will allow activity authors to use just the presence
service with their own communication stuff? (i.e. let the PS expose the
buddies ip)

Marco