[Telepathy] OLPC properties via text channel properties?

[Simon McVittie]

The OLPC activity interfaces (the activity properties interface, and the
activities and current-activity parts of the buddy properties) are currently
rather odd - they have an API that lets you claim to be in activities
you're not actually in, lets you be in activities without saying so, and
theoretically lets you change the properties of activities you're not in.

What would you think of the following API sketch? This may need to be
post-trial3, but some of it might be implementable before then.

* As per http://projects.collabora.co.uk/~monkey/telepathy-spec-smcv/,
  XMPP text channels gain a subject-changeable-by-all property which
  maps to muc#roominfo_changesubject (or perhaps
  subject-change-restricted which is the inverse, or something). OLPCs
  set it on channels they create, so anyone can change the subject.

* We map the OLPC activity title to the XMPP <subject>.

* The ActivityProperties API becomes read-only; BuddyInfo.SetActivities
  also disappears.

* For each MUC Gabble is in that has the "public" property, if it knows
  an activity ID for the MUC, it publishes the activity properties
  in PEP so they're visible to non-MUC-members. The activities
  API in BuddyInfo lists exactly those activities whose properties we're
  publishing, so in PEP we use the same node for activity properties
  and the activities list.

* If the "public" property changes, activity properties are copied to
  PEP or deleted from PEP, as appropriate.

* Invitations include a snapshot of the properties, in order to support
  non-public activities; if change notification is desirable, the
  inviter can automatically re-invite the invitee when properties change

* Either the properties are set by writing to e.g. "olpc-color" on the
  Text channel's Properties interface, or the Text channel has a new
  interface org.laptop.Telepathy.Activity. If the latter, it should
  support enumerating the allowed properties (i.e. like Telepathy's
  Properties, and unlike the current ActivityProperties and BuddyInfo).

* When users want to change the other activity properties, they send a
  <message> to the MUC with the new activity property (i.e. a
  lot like <subject>). If the activity is public, they mirror the
  property change to their PEP node on sending their own activity
  property change or receiving someone else's.

* The org.laptop.Telepathy.Activity interface may need to exist in any
  case, so we can distinguish between "quiet" invites (those that don't
  cause GUI highlighting, just an icon in the mesh view - e.g. when
  caused by widening scope) and "noisy" invites (those that cause
  distinctive GUI actions, e.g. when caused by explicitly inviting
  someone). Alternatively, we could write the OLPC stuff so it treats
  invitations with an empty message as "quiet" and invitations with a
  non-empty message as "noisy", and makes the invitation message default
  to the activity title for explicit invitations in order to make sure
  there's some message, or something.

Thoughts?
	Simon