[Telepathy] Spec meeting notes on Mail Notification interface

[Nicolas Dufresne]

I just found that two commits where missing into my public git tree.
Because of that information about IDs being uint64 and URL handling is
inaccurate. My excuses for that, please consider reading my responses
about the other good points Will have brought. The following URL was,
and is, the most up-to-date version of the Mail Notification interface. 

http://people.collabora.co.uk/~nicolas/telepathy-spec-email_notification/spec/org.freedesktop.Telepathy.Connection.Interface.MailNotification.DRAFT.html

Comments below ...

Le mercredi 20 janvier 2010 à 18:57 +0000, Will Thompson a écrit :
>         Hi,
>         
>         Sjoerd, Simon and I also gave Nicholas' MailNotification draft
>         <http://bugs.freedesktop.org/show_bug.cgi?id=13349> a look.
>         This wasn't
>         a particularly detailed review, more of an overview; we're
>         planning to
>         have another reviewing session later in the week. But here
>         some notes:
>         
>         Subscribe()/Unsubscribe():
>         • Needs rationale in the spec: we think this is because on
>         some
>            protocols you get push notification of “something has
>         changed” and
>            need to go and poll to find out what it is.

I agree this needs a rational. Subscribe/Unsubscribe should be used to
trigger notification on some protocol (like google) and to reduce
network and memory overhead if nobody is using it.

>         
>         Why are messages' unique IDs signed 64-bit integers (also, a
>         room full
>         of D-Bus hackers had to look up what “x” means!) rather than
>         strings?
>         Surely the IDs are strings on some protocols?
>         
>         Speaking of “x”: the timestamps should be signed 64-bit
>         integers, as
>         seen elsewhere in the spec (including Messages). There's a
>         named type
>         for it.

Mail ID are strings in the latest version of the protocol. The history
is that they started 'uint', but that was too small, they moved to
'uint64' but I quickly concluded that only strings would provide the
right level of flexibility.

>         
>         Maybe Mail should be aa{sv} rather than a{sv} and have the
>         first part be
>         the header, the rest the (optional) body parts, like on
>         Messages. You
>         could have a flag in the message body parts saying if it's a
>         snippet.
>         (We apparently already have one, it's called 'truncated'.)

I'm not sure I understand very well your idea for mail structure, could
you elaborate a bit ?

>         
>         HTTP_Post_Data: are they guaranteed to be UTF-8 on the wire?
>         If not,
>         then they need to be ay not s. Are they percent-encoded or
>         not?

I think it would be worth specifying that this is www-form data, so it's
ASCII (a subset of UTF-8).

>         
>         The flags' names aren't great. Perhaps:
>         • Supports_Unread_Mail_Count
>         • Supports_Unread_Mails
>         • Emits_Mails_Received
>         The flags' interdependencies are pretty hard to understand
>         well. Needs
>         some kind of truth table!

The original naming has the advantage that it uses the exact name of
properties/method that is supported. 'has' vs 'supports' is quite the
same to me, but english is not my first language, though 'has' is much
shorter.

Dependency are:
* Has_Prop_UnreadMails implies Has_Prop_UnreadMailCount
* Has_Prop_UnreadMails and Has_Signal_MailsReceived are exclusive

I can try and make it clearer, while it's all there.

>         
>         General remark: the interface needs to be clearer about the
>         different
>         features of actual protocols, with more rationale. Maybe we
>         should
>         consider splitting it into several interfaces? (Although there
>         might be
>         enough overlap not to need to... it's hard to tell without
>         rationale in
>         the spec.)

I think splitting the interface would also create some sort of
confusion. The problem is not so simple because protocols usually
disagree on what mail notification should be. I think a bit more
documentation in the top description would help though.

>         
>         InboxURL, Method, PostData could be one (sua(ss)) tuple maybe?
>         And we
>         should say that if there's no webmail URL, InboxURL should be
>         the empty
>         string. Also maybe we should have an a{sv} for misc.
>         
>         Do you always know the Inbox URL, or does the CM have to poll
>         the
>         server? If the latter, then the prop can be out of date, so
>         maybe there
>         should be no prop, and the UI should just have to call
>         GetURL() each
>         time the user clicks “take me to the cloud” to get the latest
>         set of
>         cookies etc. (They're probably one-shot, right?)

We now have RequestInboxURL and RequestMailURL methods. Cookies has been
discarded from interface since it would require some sort of system wide
cookie manager in the Linux desktop. Also, cookies sharing is considered
dangerous practice, or at least it's hard to do it safely (we need a
genius here).

>         
>         -- 
>         Will

Thanks,
Nicolas