[Telepathy] OLPC properties via text channel properties?

[Simon McVittie]

On Wed, 15 Aug 2007 at 13:57:35 +0100, Dafydd Harries wrote:
> I'm not familiar with the quiet/noisy distinction. Where does that come from?

The idea was that it lets us do group-scoped activities without actually
understanding groups - just have the PS or even the UI tell Gabble to
invite everyone in the group individually, and mark it as "quiet". That
gives us Eben's desired behaviour (icon appears in mesh, no notification
in frame) at the other end, but without CMs and Telepathy having to
understand the OLPC-specific "group" concept (minimizing OLPC-specifics
in the CM sounds like a win to me).

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

Got it

>  - who the invitation is from

Can have it easily

>  - the activity's colour

Got it

>  - the colour of the person who sent the invitation

Trivially derivable from who the invitation is from

>  - when the activity was started (I assume this is the start time of the
>    latest instance, not the time it was first started)

I've never seen that requirement before, but we can introduce a new
activity property

>  - description

We can introduce a new activity property

>  - who the members are

This needs more information stuffed into the invitation in XMPP/Salut;
representing it via the group interface seems sane.

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

The former needs "invitation revocation" which doesn't exist in XMPP, so
we'd have to invent it.

The latter needs updated invitations to be sent when the members list
changes. I suggest we consider invitations to be per (room, inviter)
pair, so any invitation to an activity from a particular person
supersedes all previous invitations to that activity by that person. The
coalescing could be done inside Gabble.

Hmm, thinking about it, in Telepathy we only represent one invitation
per room (the first one) because re-invitations don't result in a
MembersChanged signal. Perhaps re-invitations should result in you being
removed and re-added to local-pending, or in a MembersChanged signal with
all sets empty, but with the actor and message given, and reason Invited.

	Simon