Bug 28740

Re GetContactListAttributes: I find it sad that special timeout has to be written for this method; is it a generally accepted practice across Telepathy? This will require special work for bindings and clients.

Maybe a property/signal pair could be added so that clients could wait on the signal, and know that GCLA will return empty if called while contact list synchronization is pending?

(In reply to comment #1)
> Re GetContactListAttributes:

Oops, please ignore this misplaced comment.

> 3. CMs may set this header on messages; clients must not set it (e.g.
> message-token¹)

What was footnote 1 meant to be?

> CMs may support this header on messages; clients may set it (currently just
> sender-nickname; this also applies to most of the headers I'm defining at the
> moment like message-subject, supersedes (bug 25636), message-validity (SMS),
> message-to/cc/bcc)
...
> [This] class is a problem. How does the UI know that it's on MSN using
> Butterfly, and hence can set sender-nickname? Ditto XMPP and message-subject;
> Skype (and maybe ll-xmpp) and supersedes; etc.
> 
> I think the way to do this is to split the fourth set out in the spec, and have
> a property listing which extra properties clients can set on outgoing messages
> on this channel. (The property is immutable, but isn't requestable so doesn't
> really fit in RCCs, which is a bit annoying.)

All(?) current implementations just ignore unrecognized headers, which is the behaviour I intended Messages to have.

I think this subdivides further:

4a. "Unimportant" hints. CMs may support this header on messages; clients may set it. If the CM doesn't support it, it's ignored, and that's OK; the message was delvered in a best-effort way. If the CM indicates that it doesn't support it, the client MAY hide the UI for it, or just send it unconditionally.

IMO, message-validity and sender-nickname are in this class, and probably supersedes too - if you don't understand how to supersede messages, the fallback behaviour of treating the new message as independent is ugly but legible. Whether subject is in this class is debatable.

4b. Important semantic differences. CMs may support this header on messages; clients may set it, but should not set it if unsupported, because the behaviour if it's not understood will differ significantly.

I'd assumed that message-to, message-cc and message-bcc were in this class, but having read your branch again, I'm not so sure: the intention of the branch seems to be that the recipients are determined by the channel's members. If you set message-bcc:[Bob] and the CM doesn't understand it, then the fact that Bob is a recipient is leaked, but that's the best you can do on a protocol where recipients of multi-recipient messages are always revealed to other recipients.

(In reply to comment #4)
> IMO, message-validity and sender-nickname are in this class, and probably
> supersedes too - if you don't understand how to supersede messages, the
> fallback behaviour of treating the new message as independent is ugly but
> legible.

For outgoing messages, the UI needs to know whether it should suggest to the user that it can edit messages.

For incoming messages I agree.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/74.