[sugar] activity sharing protocol

[Robert McQueen]

Marco Pesenti Gritti wrote:
>> is known to work in resource-limited environments
> 
> Just a curiosity, in which environments have it been used?

On the Nokia 770 and N800 Internet Tablets, so 64/128MB RAM and
180/400MHz processors respectively.

> 100 contacts seem too limited, or at least out of proportion with 30 per
> activity. Maybe a more realistic proportion is 1/10.

Our original thought was that the school would have one server, so ~1000
or somesuch, but Dan said that due to the need to split stuff up across
RF channels, and the potential that a server would just be another
laptop with maybe an uplink to other servers. So our working assumption
currently is that we can have several servers in one school, each one
serving ~100 users directly, and they can route to each other to see the
other users.

> Even assuming free JVM, is it worth to have a JVM installed/running for
> just this?

This is just for the server, but ejabberd looks like it has better
support for PEP at the moment, and I think its less resource intensive
than Wildfire anyway, so it'll be our first port of call.

>> 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.

This was just us pondering whether it was worth buddies publishing all
their current activities via the server, or just the active one. All of
them isn't too much of a hardship.

>> 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.

It's kinda an implementation detail, in that we need to put a limit on
how many people the PS will collect/cache info for, and a limit on how
much bandwidth it will use retreiving information, but to get this right
we need a clearer idea of the people and activities we want to be able
to show in the desired UI. We don't want a situation where the PS is
pulling down info about 100s of buddies but sugar is choosing to show
only a small fraction of them.

>> 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.

This is just about mapping concepts. In Telepathy (and IM in general)
you can get one to one messages and calls, and in the UI we only have
concepts of activities, so we were thinking of "upcasting" these to
activities to display in the UI. Otherwise we need a different way to
represent these one-to-one tasks.

>> 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.

Implementation-wise, it's very hard to think of a sensible way to have
an activity where some users are on the mesh and some are on the server,
without ending up using someone as a relay, in which case why can't the
other mesh users see the server using him as a mesh node? For migrating
all of the mesh users to server users "atomically", this could be
arranged by the PS looking at when all of the mesh people are visible
through the server, and then arranging a migration then.

>> 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.

Yeah, I think thats what we thought too.

>> 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.

The current concept is that the presence service will sheperd the
Telepathy connections for XMPP and link-local, and pick up the buddies
and activies that are deemed relevant, and make them available as Buddy
or Activity objects for use from Sugar, similar to the current API.
Where it differs is that rather than having Channels and Services
exposed in the PS API, we just pass the Telepathy Channels involved up
to the UI, and the other concepts (tubes) are exposed there and
implemented by interacting directly with the backends.

>> 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.

The problem is about finding people. If you're on mesh channel #6 and
talking to a server on #6, and the guy who's sitting next to you is on
mesh channel #11 and talking to /his/ server, even if you can talk to
him via the server with IP routing, you're not going to see him on your
mesh.

I don't think it's very scalable to consider the presence service being
aware of every single buddy within eg a school. Seeing everyone on your
mesh, plus everyone you've marked as friends, and then maybe picking up
some extras from the server, would be more reasonable. If you consider
the potential traffic from them changing activity etc, so we think some
"relevance" heuristic is necessary. But as a consequence of network
topology you can end up not seeing the person next to you. :-/

>> 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).

Yeah, this just follows on from the not having all the information about
everyone all the time. You can search the people you can see over mesh
easily because you get given the mDNS stuff all the time, but searching
1000 people on several servers is tricky. Jabber only has a concept of a
User Directory which is searchable by name, alias and e-mail address. Do
we need to build something better than this on the server in order to
allow the PS to launch searches for people?

>> 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.

That's not quite the case. I think we have a reasonable idea of what
shape the API will have, and we've identified some clear areas where we
need to modify Telepathy spec/backends to provide extra features, so we
can get started on some of this whilst the higher level stuff is nailed
down too.

> Marco

Regards,
Rob