[Telepathy] OLPC properties via text channel properties?

[Dafydd Harries]

Ar 13/08/2007 am 23:16, ysgrifennodd 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>.

+0. I'm not certain whether this makes things simpler or not. On the one hand,
we have support for the subject already; on the other hand is means special
casing the property.

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

Er, so how does Gabble know what proeprties an activity has? If it's joining,
it gets them from the network, but they have to get on the network somehow.

> * 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

+1

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

+1

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

I'm not familiar with the quiet/noisy distinction. Where does that come from?

When I talked with Eben about his UI, he mentioned wanting to have the
following information for the UI:

 - activity name
 - who the invitation is from
 - the activity's colour
 - the colour of the person who sent the invitation
 - when the activity was started (I assume this is the start time of the
   latest instance, not the time it was first started)
 - description
 - who the members are

Sorry for not passing this information on sooner.

I think the start time and description can be included in the properties. The
inviter's colour and list of members should be special case.

The member list can be represented using the Group interface.

It was pointed out that there can be a gap between the invite being sent and
the user receiving it (due to being away from the laptop). This raises a
number of interesting problems:

 - we would like to be notified if the inviter leaves the activity
 - we would like the member list to be updated (some kind of invite merging?)

These are wishlist features, though.

-- 
Dafydd