[sugar] Requirements for activity and buddy properties needed

[Eben Eliason]

> Activity bundles are not currently automatically retrieved (or if they are,
> it's through some mechanism that has nothing to do with us).

OK.  I know that's been the intent.  I'll have to see what the goals
are for trial 3 in that regard.  We may ignore it for now, though I'd
rather not have a bunch of instances where silent failure occurs come
FRS.

> > 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).
>
> This lag is pretty much unavoidable, in the "inviter fell off the network"
> case - they've just fallen off the network, so they can't possibly tell you "by
> the way, I disappeared"! In the "inviter left of their own accord" case,
> yes, they could send an explicit "uninvitation" at that time.

Right.  Network instability aside, sooner is better.  Still, I'm not
going to put up a strong fight for this in the near term.  There are
more important items to focus on for sure.

> > 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.
>
> ... and that's why we've deemed that this problem is out-of-scope for
> Telepathy, which is what I'm trying to design right now.
>
> > The trickier part is what happens when they come back in contact.  With the
> > PS signal the activity when the participants are present again?
>
> In my proposed design, the Telepathy CM will emit a signal when
> participants rejoin. I'd expect the activity to listen for these signals
> rather than having PS forward them, at least until/unless Bitfrost makes
> this impossible.

As a clarification of terms, should this signal be emitted when the
participants *reappear*?  That is, I interpret "rejoin" above as an
explicit action, whereas I'd expect that the PS/activity/Sugar all
work together in some fashion to decide if an implicit rejoin should
happen at the activity's behest.

> > 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 think the only way we can do this sanely is for the activity to make
> the decisions and signal back to Sugar somehow. Out of scope for
> Telepathy, anyway.

Yup.

> > 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)?
>
> Implicit; it'd probably be the Presence Service that's responsible for
> sending re-invitations, and for inferring from the absence of a
> re-invitation that the invitation has expired.

Sounds good.

- Eben