[sugar] Requirements for activity and buddy properties needed
Wed Aug 8 12:03:13 EDT 2007
On Wed, 08 Aug 2007 at 10:11:40 -0400, Eben Eliason wrote:
> 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
Activity bundles are not currently automatically retrieved (or if they are,
it's through some mechanism that has nothing to do with us).
> 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.
> 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
> 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
> 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.
More information about the Sugar-devel