[sugar] activity sharing protocol

[Marco Pesenti Gritti]

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.

Marco