[Bug 13349] Review mail notification spec

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13349





--- Comment #20 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-02-17 11:37:10 PST ---
I've fixed various typos and made clarifications and editorial changes in
<http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/mail-notification-editorial>
- Nicolas, please review these, and merge them into nicolas/mail-notification
if you approve?

Things I still don't like, after that branch is merged:

Mail_Type distinguishes between "is a mail" and "is a thread". A thread isn't a
type of mail :-P so I think this should be called Mail_Notification_Type (both
a Mail and a Thread could be said to be types of mail notification). Perhaps
Mail should be renamed to Mail_Notification, too?

Subscribe is documented to raise Disconnected and NetworkError (which I can
understand), but also NotAvailable and PermissionDenied (which I can't). When
would it raise these errors?

sent-timestamp, received-timestamp are meaningless for threads, as currently
written; please either forbid them for threads, or re-define them as "the most
recent" or "the oldest" (your choice).

MailsReceived allows 'id' to be non-unique, which directly contradicts the
definition of 'id'. Possible resolutions:

(A) Change the 'id' uniqueness requirement so it only applies if
Supports_Unread_Mails is set. This seems weird and undesirable to me - the
guarantees provided by a particular key should either always be set, or never
be set.

(B) Relax the 'id' uniqueness requirement from "unique per Connection" to
"unique until removed". This is basically the same change as (A), to be honest
(since on protocols without Supports_Unread_Mails, you can't tell whether a
mail was removed), but it seems like a nicer way to explain it.

(C) Require 'id' to be either unique or omitted, and munge the necessary info
into url-data on protocols where IDs are non-unique. On MSN, this brings you
back to the situation you wanted to avoid...

(D) Change url-data so it can have any type, and change the signature of
RequestMailURL to RequestMailURL(v: URL_Data) or RequestMailURL(s: id, v:
URL_Data); in MSN, omit the 'id' if it can't be guaranteed to be unique,
but put the URL data in the map as a pair of strings (id, POST data) or
whatever. This requires the client to remember a GValue (or QVariant) rather
than just a string, but lets the Connection put anything it wants in it
(integers, strings, binary blobs, whatever).

(E) A restricted form of (D): change url-data's type to 'as', and change the
signature of RequestMailURL to RequestMailURL(as: URL_Data) or
RequestMailURL(s: id, as: URL_Data); in MSN, do basically the same thing as for
(D).

(F) Anything cleverer that someone comes up with :-)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.