[sugar] Requirements for activity and buddy properties needed

[Eben Eliason]

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


Well, there are already a fair number of activities that don't come
installed on the machine, and we need to expect that some people will
download and use these.  I could be wrong, but I *think* that the activity
bundles are automatically retrieved when one joins an activity they don't
have.  I could be wrong.  Either way, I think we need to handle this case up
front.

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.


Yeah, that sounds best.

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


That could work reasonably well.

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


Ah, I see.  Well looking at it solely from a user experience perspective,
I'd say we need to do this.  Of course, you could implement it by revoking
the invitation when no more invitation renewals come through, but then you
will most likely have a delay of several minutes between the time your
friend leaves (or the activity disappears) and the invitation goes away. It
would be much better to have that feedback sooner (immediately).

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


Well, signaling the activity on the split isn't the hard part, right?  I
mean, Abiword would probably carry on with 2 people in each session instead
of 4.  Connect would probably run some turn timer, waiting for the missing
player for a short time, and then eventually drop them out of the game.

The trickier part is what happens when they come back in contact.  With the
PS signal the activity when the participants are present again?  It sounds
like Sugar is going to need some well finessed ways of communicating with
the activities here in order to do the right thing in UI. For instance, if
connect is still waiting for the missing player, who comes back, it should
happily allow them to rejoin the instance and continue playing.  If one or
both Abiword documents changed in the meantime, it might require assigning
them separate version numbers and tell sugar to "split" them in the UI, so
that both appear independently on the mesh.  I agree it's up to the
activity, but Sugar has to be told how the activity wants to handle it.

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


Yeah, that's interesting.  To be even more clear, do you mean that this
would be an explicit renewal (The kid says "It's been a while since I
invited Bobby, let me go invite him again") or implicit (Sugar recognizes
that I'm still participating in the activity I sent an invitation for and
automatically sends renewals on some interval)?

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070808/a75fd62b/attachment.htm