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 _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
