[sugar] Requirements for activity and buddy properties needed

[Simon McVittie]

On Tue, 07 Aug 2007 at 23:41:11 -0400, Eben Eliason wrote:
> > So... you want per-activity-instance icons? That's a requirement I've
> > never heard of: currently, the icon is 100% determined by the type (e.g.
> > Paint) and the color (i.e. it's the activity program's icon as it
> > appears in the donut view, with colors adjusted to match the initiator's
> > colors).
> 
> No, I just got confused with the terminology; the relationship of activity
> type identifier to icon should be one to one. My main point is that not
> everyone will have every activity, and therefore not everyone will know
> locally what the icon for (say) org.laptop.Paint is.  If we only send the
> string over the mesh, and not the SVG itself, there needs to be a protocol
> that asks for the associated icon. It's quite probable that this is already
> handled, and I just don't know the details.

Ah, I was assuming kids who don't have the right activity yet just wouldn't
see it (which is a better short-term plan I think).

If you want uninstalled activities to be visible, we need to be able to
send the icon and list of localized (translated) names, probably only on
(an automatically-made) request.

> I think I'm going to defer that until I can talk about it from a design
> perspective with Pentagram and others.  On the technical side, I would argue
> that it's not necessary make this event driven.  If a new snapshot is taken
> every few minutes it might be adequate enough.  You could also send the list
> as a diff, to minimize bandwidth a bit.

Relying on diffs would give us a fragile network protocol and isn't how
XMPP usually works, so no, we can't really. If we decide that invites
that aren't renewed disappear from the UI, I suppose the renewal could
include an updated members list.

> Could you, similar to the "quiet invitation" add one more bit for "revoke
> invitation"?  You could omit the other details in the revocation to save
> bandwidth, needing only the activity ID, perhaps.

I don't know, I'd have to look at the underlying protocols. (We're trying not
to reinvent more wheels than necessary - XMPP, in particular, is a
well-established protocol with a well-established invitation mechanism,
which we use. It's XML-based and extensible, so on the negative side, any
ideas of "it's just one more bit" are untrue, but on the positive side, it's
not impossible to stay network-compatible while making changes.)

> Hmmm, good point.  We need to come up with some guidelines for what happens
> when connectivity is intermittent.  In the worst case (probably average
> case), one or both of the separated versions will change in the meantime.
>  Perhaps there's some small amount of leniency built into the system which
> will automatically rejoin the active instance on the mesh and take on that
> versions changes.  Of course, that depends upon implicitly deciding which is
> the active one, which you could try to do based upon number of participants,
> but you can't rely on in any case.

We've thought about this quite a lot, and we can't think of a good
solution. This is a general problem of distributed anything (the "split
brain" problem).

Our solution in the end was to signal the "netsplit" to the
PS/the activity and let activities handle it on a case-by-case basis
(e.g. Connect-4 and Abiword should have completely different handling).

> I suppose invitations might eventually need to time out after a while
> 
> unless renewed, or something (at least from the UI's perspective). More
> > network traffic, but better failure modes.

To be clear: what I meant here was "time out unless refreshed", so the
inviter is required and expected to re-send the invitation every so often
as a way of saying "still here". If the invitee doesn't get a re-sent
invitation for a while, they stop showing it on the assumption that the
inviter has gone away. Or something.

Right, off to see the wizard^W^W^Wmove the office...

	Simon