[sugar] activity sharing protocol

[Marco Pesenti Gritti]

On Mon, 2007-02-19 at 14:04 +0000, Robert McQueen wrote:
> >> 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.

This sounds good.

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

Sounds good.

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

This needs to be discussed in detail with the design team. We needs to
define what's the mesh meaning relatively to the network topology, to
what search applies etc. And then base the implementation on these
concepts. Tomorrow we have the weekly design conference call. Maybe you
guys could join for at least part of it? I think it would be important
to clear out the issues...

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

What I actually meant there is that it was difficult for me to comment
on the implementation plan without having an idea of the API. Your
answers above was helpful in this respect.

> Basic multi-user chat, some regressions from existing presence
service.

What regressions do you anticipate? We hooked up a lot of the PS
functionalities in the UI. One of the high priorities for Sugar is to
get the Mesh infrastructure to work (both UI and network API) so that
activity authors can start to use it. The sooner we get at that point,
the better.

> API for chats

How this is different from tubes? Do we plan to have something chat
specific?

Finally, do you feel like making any time estimates on Phase 1/2. Not
knowing enough about telepathy, I don't have any idea of how much work
they would be.

Thanks!
Marco