[sugar] Requirements for activity and buddy properties needed

[Walter Bender]

On 8/7/07, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Either for Trial3 or shortly afterwards, we want to rethink the design of the
> activity and buddy properties Telepathy interfaces, so the code makes more
> sense. I want to get this sorted out before we go any further on implementing
> activity invitations, since each activity invitation will have to
> contain all the activity's properties; even if we defer the redesign til
> post-Trial3, we should have the rethought version in mind when
> designing invitations.
>
> In particular I'd like input from Eben, since many of these are driven
> by UI requirements, and from Dan Williams because of the Presence
> Service angle.
>
> Assumptions
> ===========
>
> Please tell me if any of these are wrong:
>
> Contacts ("buddies") have the following non-transient properties:
>
> * a name to be displayed in the UI (Unicode string)
> * a public key (binary data)
> * a color (ASCII string constrained to be in the format #xxxxxx,#xxxxxx
>   where x is any hex digit)

We may want to consider some additional parameters, such as end-points
and knot-points, in case the children want to change the shape of
their XO (this could be up to 9 x,y coordinate pairs. 8 bits per digit
would be adequate. We'd probably want to pass around deltas so that by
default we are just sending 0s.

> * a JID (Jabber ID, which is the unique identifier in XMPP) on the server
>   (for people you see on the server this is obvious, for people you see on the
>   mesh you want to be able to remember it for future reference)
> * an "avatar" photo or image (binary data, JPEG or PNG, ~96x96 pixels)
> * an IPv4 address for legacy activities (ASCII string, "123.45.6.78",
>   deprecated)
>
> Properties will only be added slowly, so it is acceptable if each new
> property needs changes to the connection managers and to Presence Service.
> Properties beyond the above will be optional.
>
> Each child has a "home" XMPP server which is (at least initially) the one they
> were assigned to when their XO was activated. The server has a globally
> unique DNS name (I'll assume here it's foo.schools.laptop.org) and the child's
> JID is of the form something at foo.schools.laptop.org.
>
> Whenever the child's XO and the XMPP server both have unrestricted Internet
> access, the XO will be able to log in to the XMPP server - they aren't
> forced to log in to the nearest XMPP server, the same way you can log
> in to olpc.collabora.co.uk (which is in London) from America. Whenever
> the XO can't make a TCP connection to its "home" XMPP server, it will
> only have link-local connectivity using Salut, with all the restrictions
> that imposes.
>
> Activities are implemented as chat rooms - there is a 1<->1 mapping
> between (shared/shareable activity instances) and (chat rooms). The chat
> room implements the text messaging and Tubes interfaces.
>

This is important, but as per the discussion below, I am not sure it
should be activity based or group based.

> A child can be in multiple activities.
>
> Shared/shareable activities have an ID which is pseudorandom, assumed to
> be globally unique, and immutable.
>
> Activities have the following properties:
>
> * Name (human-readable Unicode string, changeable)
> * Color (string in the same format as buddy color, immutable)
> * Type (string in the format of a D-Bus service name, immutable - this
>   is what sets the icon in the mesh view)
> * Tags (list of human readable Unicode strings, semantics unspecified at the
>   moment, changeable)
>
> 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.
>
> 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.
>
> It is acceptable if changes in the activity name aren't visible in the
> mesh view for a minute or so, but they must be reflected in the mesh
> view eventually.
>
> If activities need activity-specific "properties" these will not be needed by
> the mesh view, and the activity will have to use its Tubes channel (or
> something) to propagate these. (Loosely: they're not our problem. :-)
>
> Activities can either be:
>
> * unshared (from Telepathy and the PS's point of view, equivalent to not
>   existing)
>
> * invite-only (exists as a chat room, but not publicized; does not
>   appear on the mesh view unless you've been invited; does not appear in
>   server room listings; any participant can invite others to join in)
>
>   (This type does not exist at the moment, but is a goal for Trial3)
>
> * public (may appear on anyone's mesh view; anyone may join)
>
> When someone is invited to an activity they will be sent enough
> information to put it on their mesh view.
>
> If buddy groups are implemented, we plan to make them purely a UI thing -
> if sharing an activity with "My Class" is implemented at all, the UI
> should do this by creating an invite-only activity and sending
> invitations to everyone in the group "My Class". This keeps the
> Telepathy interface relatively simple.
>
> Children who are not in an activity can't change anything about it
> and if Presence Service tries this, it should expect it to fail.
>
> Questions
> =========
>
> Can children change their names?
>
> If so, how acceptable is it for other children to continue to see the old name
> indefinitely? Required, recommended, acceptable, grudgingly allowed,
> unacceptable? (We can reduce traffic significantly if we're allowed to
> save the child's original name to the XMPP roster)
>
> Can children change their colours?

I think we need to support this: children will want to use their XO as
an "away message."  It need not change rapidly, but I suspect that
children will change it on the order of 1-2 times per day.

> Can children change their photos?
>

This is also something we need to enable, but with the assumption that
it changes much more infrequently: once per semester perhaps.

> Can the child's "home XMPP server" change, i.e., can their JID change?
>
> Is ip4-address still required or can we drop it? Is an IPv6 address required
> in buddy properties?
>
> Do we need the concept of a buddy's "current activity"? (Currently it's
> implemented, but in practice is write-only)
>
> Who is allowed to cause a change to an activity's name? The initiator?
> Anyone in the activity?
>
> How do tags work? Who can change them? If a child adds a tag, can a different
> child remove it? (We're unlikely to support these for Trial3 anyway, I think)
>
> Who can change the "sharing level" of an activity? Which transitions
> between states are allowed?
>
> When a child is invited to an invite-only activity, how many of that
> activity's members must they be able to see? The simplest thing to
> implement would be that they see that the inviter is in the activity,
> but they don't know who else is in the activity until they join. An
> alternative is that they see everyone in the activity at that moment (because
> the inviter tells them), and their mesh view continues to show those
> members indefinitely. Are either, both, neither of these acceptable?
>
>         Simon
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net
>
> iD8DBQFGuLp/WSc8zVUw7HYRAv8YAJ47ZblCBL3+5hbEWOaOT2t3PCU8zACcDjKZ
> 6hvKMUqytmPJepHwi4eo3sY=
> =wYz6
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>


We have been having discussions about shared activities versus groups
versus projects. Depending upon how these discussions unfold, we'll be
able to better answer your questions.

Personally, I am of the opinion that the more natural use case is that
children will engage in short-term joint activity sessions (playing a
game of chess or a shared record session) but longer-term joint
project sessions (running a collection of activities--e.g., record,
browser, write--towards the goal of pulling together a joint report.)

We are far from consensus in this, I think that we should be focusing
on defining persistent work groups with associated chats and common
workspace (bulletin board) that appear in the group view as a means of
handling these latter cases. I don't think we need to do much more
that what we already have for temporary share activities; they are by
their nature ephemeral. (Beyond the ability to advertise to either the
mesh as a whole, a group, or an individual is enough. Everything else
could be handled with the activity.) This begs the question of how you
form a group (I believe making this process simple is important --
work groups and teams are used a lot in the field and we should have a
goal of facilitating this). It could be, but doesn't have to be, the
same mechanism as issuing an invitation.

-walter

-- 
Walter Bender
One Laptop per Child
http://laptop.org