[sugar] Requirements for activity and buddy properties needed

[Simon McVittie]

A lot of this looks like a wishlist for the future rather than something
we can implement in the short term, I'm afraid... I think the only
user-visible feature we'll be adding in the near future is invitations.
We'll try to design in ways that don't prevent what you've asked for in
future.

On Tue, 07 Aug 2007 at 19:44:30 -0400, Eben Eliason wrote:
> This may be quite silly, but if it's 90x90 px it will fit cleanly into the
> grid we've been using for designs. Since it's not a power of two, I'm not
> sure why 96 is the blessed number.  Are there technical reasons here?

That would be fine too. The important thing for me is "it's small". 96px
just happens to be the size PS currently scales to (well, the size it
scaled things to before we removed that feature so we could have our
performance back).

> They will also have a version identifier of some kind, which may need to
> relate to the activity identifier when we decide what is actually
> represented on the mesh.  We're still discussing details in this area.

Well, I've been told we have feature-freeze on Monday, so that's
going to have to be a future addition.

> A few notes on activity properties...
> the Kind of the
> activity (eg. "Paint"; not listed above)

That's the "type" in our spec - we use a centrally defined D-Bus service name,
e.g. org.laptop.Paint or something, and assume that the UI will localize it
appropriately. As currently implemented, it does, at least into English;
I assume other localizations are just a matter of writing the translations
in the .activity file.

> and the Icon (Type above seems to
> relate here, but I think we need to directly associate the icon and not just
> its identifier; how does this work?)

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

> As for color, we have put some thought into the version history system, and
> have a potential use for associating different color pairs with different
> versions in the history.  This is still immutable from the perspective of
> the kids, of course.

Is this something for which we need to transfer information over the
network, or can the color be determined by asking the journal? For the
purposes of this email I only care about information going over the
network. Again, this is a requirement I've never heard of before.

It simplifies the implementation massively, particularly on Salut, if
once an activity chat room has been opened, most/all of its properties can't
change at least until everyone leaves. Obviously we'll have to make an
exception for the name and (if implemented) the tags.

> Regarding tags, I won't get into details here, but we also have ideas around
> tags which require each tag to have an associated identity (unique ID for a
> buddy and a color pair) for use in displaying the tags. If we do follow this
> approach, we'll need a more complex data structure for the tag list.

It's looking as though tags can't happen for Trial 3 or FRS; we certainly can't
implement "a more complex data structure" without knowing in advance what it
*is*, and the feature freeze date is rumoured to be Monday.

> which are set when the activity is created, and are required to be
> > visible in the mesh view to children who have not joined the activity.
> 
> It won't be required that every child see every activity.  Only activities
> which the child is able to join should be shown in the mesh (at the moment,
> this simply means any shared activity, but in the future we may have more
> scopes which limit who can see what on the mesh).

OK, perhaps that was badly phrased. The assumption I wanted you to
accept or reject was that for an activity to be shown in the mesh view, it is
sufficient to know the properties I listed (plus members, but that's a
bit different anyway).

> No other information is required to be visible in the mesh view, and
> > properties will be added sufficiently slowly that it's acceptable to
> > require
> > changes to Gabble, Salut and PS for each new property.
> 
> 
> We also have a notion of an activity Description, though semantics are not
> defined here either.  This description could appear on the mesh, and also
> has a place in the Journal.  We're not sure how to reconcile different
> Descriptions across versions and across different kids' Journals.

We can't implement something with unknown semantics, so this will
have to be delayed until we know what to implement.

"Description" makes me think "likely to be multiple sentences". There is a
quite small limit to the amount we can store using the current mechanism
on Salut, so we'd need to think about using a different mechanism. Not a
problem necessarily, but it makes this a larger feature to implement, so,
later.

> We also need to associate the list of participants with an activity,
> regardless of how this is shown in the UI.  Obviously we would like to group
> the XO icons around their active activity.  We may also want a list of the
> names of the participants in the rollover for an activity on the mesh.

Yes, we track who's in an activity. At the moment we let people claim to
be in activities they're not, and claim not to be in activities they
*are* in, but I'm going to remove that "feature" if I redesign the API -
it was intended to make implementation easier in Gabble, and indeed it
does, but it makes the implementation in Salut much more complicated.

> There is a 4th kind which might also be a trial 3 goal.  We'd like "group"
> activities, such that all the members in a given group can see any
> activities that are shared with that group, without needing an explicit
> invitation.

I don't think it's feasible for the connection managers to know about
groups for Trial3, and architecturally I don't think it's a good idea
anyway.

There is a way to get the same UI-visible result with less code,
although that probably won't be feasible for Trial 3 either.
As a future enhancement we could add API for sending "quiet" invitations
which are basically the same at the Telepathy/XMPP level, but are handled
differently by the UI (i.e. just quietly put the activity on the mesh view
without doing the special invitation handling in the frame). Then the UI
could use "quiet" invitations when people are invited due to a scope
widening.

> I do want to point out, however, that any activity to which
> you've been invited should remain on the mesh even if you decline the
> invitation.  It should always be accessible to you in the future.

That's the mesh UI's concern... I don't plan to make that impossible.

> We talked a lot about this in terms of security.  I think the current idea
> here is that children CAN'T change them, at least without a reasonable
> amount of effort.  When they change their name, they essentially take on a
> new identity and need to be reintroduced to everyone.  Short answer is no.

So, our planned performance improvement can work. Good.

> Can the child's "home XMPP server" change, i.e., can their JID change?
> 
> I assume this is the registration question.  There is a ticket about it, and
> the current idea is to present a "register" action within the secondary
> rollover for a school server, so that a child can re-register when needed.
>  I don't know the technical details.

For this to work, there will have to be considerable coordination
between PS, registration and security. Not feasible for Trial3, but we
can try to plan the API so we won't gratuitously break this.

> > Do we need the concept of a buddy's "current activity"? (Currently it's
> > implemented, but in practice is write-only)
> 
> 
> Absolutely.  Once we have the grouping UI implemented in the mesh, we need
> to associate an XO icon with only a single activity at a time.  The "current
> activity" provides this possibility.  The granularity with which this
> property is known on the mesh is arbitrary.  I don't think it needs to be
> event based, necessarily.

OK then, follow-up question: Suppose Alice and Bob are in an invite-only
activity, ID abcabc. Their current activity IDs are advertised to the
world (as all the buddy properties are). Charlie can look at their
activity IDs and infer that they're in an activity together, even if
it's not possible to tell anything about that activity. Is this
acceptable?

(If not, considerable work will be needed to support this. For Trial3 I
don't believe this to be feasible.)

> I prefer the latter in the sense that I'd like to know who is in an activity
> before I join it.  On the other hand, I don't like the idea of transmitting
> a list of participants which could soon become stale. Ideally, the act of
> receiving an invitation (without yet opening it) should render the
> associated activity within the mesh  just as the rest are represented.

That's what I'd feared. That's technically possible, but causes more
protocol complexity and more network traffic (every time someone joins
or leaves the activity, everyone who has sent invitations has to
contact the people they invited and tell them about the membership
change). If we can't do that, which of my suggestions is less bad,
"just the inviter" or "stale snapshot of members list"?

> Also, we should probably revoke an invitation if the inviter leaves the
> activity.  Ideally, the invitation would simply disappear as though it
> hadn't ever existed when this occurs.

Depending how we implement invitations in Salut, invitation revocation
may or may not be technically possible. In Gabble we're somewhat at the
mercy of the server software - I don't know offhand whether XMPP handles
invitation revocation.

It would be possible to tell the UI it's no longer welcome (i.e. get it to
stop displaying an icon, at least), although again that's more complexity.

> This automatically handles the case
> when the activity is no longer present on the mesh at all, which is a
> concern even if we don't revoke it when the inviter leaves.

You're assuming here that people always leave activities voluntarily, I
think. If someone just drops off the network (maybe they walked out of range
or their battery ran out), they're in no position to notify anyone about
anything (which causes some bugs already).

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.

	Simon