<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, I was assuming kids who don't have the right activity yet just wouldn't<br>see it (which is a better short-term plan I think).
</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">If you want uninstalled activities to be visible, we need to be able to<br>send the icon and list of localized (translated) names, probably only on
<br>(an automatically-made) request.</blockquote><div><br class="webkit-block-placeholder"></div><div>Yeah, that sounds best.</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> I think I'm going to defer that until I can talk about it from a design<br>> perspective with Pentagram and others. On the technical side, I would argue<br>> that it's not necessary make this event driven. If a new snapshot is taken
<br>> every few minutes it might be adequate enough. You could also send the list<br>> as a diff, to minimize bandwidth a bit.<br><br>Relying on diffs would give us a fragile network protocol and isn't how<br>XMPP usually works, so no, we can't really. If we decide that invites
<br>that aren't renewed disappear from the UI, I suppose the renewal could<br>include an updated members list.</blockquote><div><br class="webkit-block-placeholder"></div><div>That could work reasonably well.</div><br>
<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> Could you, similar to the "quiet invitation" add one more bit for "revoke<br>> invitation"? You could omit the other details in the revocation to save
<br>> bandwidth, needing only the activity ID, perhaps.<br><br>I don't know, I'd have to look at the underlying protocols. (We're trying not<br>to reinvent more wheels than necessary - XMPP, in particular, is a
<br>well-established protocol with a well-established invitation mechanism,<br>which we use. It's XML-based and extensible, so on the negative side, any<br>ideas of "it's just one more bit" are untrue, but on the positive side, it's
<br>not impossible to stay network-compatible while making changes.)</blockquote><div><br class="webkit-block-placeholder"></div><div>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).
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Our solution in the end was to signal the "netsplit" to the<br>PS/the activity and let activities handle it on a case-by-case basis
<br>(e.g. Connect-4 and Abiword should have completely different handling).</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> I suppose invitations might eventually need to time out after a while<br>><br>> unless renewed, or something (at least from the UI's perspective). More
<br>> > network traffic, but better failure modes.<br><br>To be clear: what I meant here was "time out unless refreshed", so the<br>inviter is required and expected to re-send the invitation every so often
<br>as a way of saying "still here". If the invitee doesn't get a re-sent<br>invitation for a while, they stop showing it on the assumption that the<br>inviter has gone away. Or something.</blockquote><div><br class="webkit-block-placeholder">
</div><div>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)?
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div></div>