[Telepathy] OLPC properties via text channel properties?
simon.mcvittie at collabora.co.uk
Mon Aug 13 15:16:59 PDT 2007
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
* 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.
More information about the Telepathy