[Telepathy] Spec meeting notes on Mail Notification interface

[Nicolas Dufresne]

Le jeudi 21 janvier 2010 à 11:03 +0000, Simon McVittie a écrit :
> What happens if one client calls Subscribe() twice, then Unsubscribe() once?
> Is it still subscribed or not? Must implementations track the unique name of
> clients that have called Subscribe() to see if they crash?

I forgot to review the policies to make sure they are all covered. When
a client subscribes a second time, an error should be returned. If the
client crash or quit, the CM must detect it and unregister it. An error
should be return if unsubscribe is called without being subscribed. That
work is common to all CM and should be put inside a Mixin in tp-glib,
base class in tp-python, etc. At the moment I see double subscribe with
same name as an error, but the difference in implementation is very
small so if it really makes life easier I would agree (anybody has a use
case they want to share?).

> You've invented a somewhat elaborate data structure to represent a message.
> However, the Messages interface already has a similar data structure (which
> can also deal with more complex messages). It may be worth representing a
> mail in the same way as a Messages message, and just defining some extra
> fields ("mail-from", "mail-cc", "mail-to", "mail-is-thread" etc.) and
> forbidding some of the Messages fields from appearing in the MailNotification
> interface where they don't make sense (like "message-sender").

I'll have a look and come back soon. By the way, I'm not the inventor,
this was in the original draft by Olli (rebased by Will) that I
reworked. I kind of agreed that a single hash table was not very
elaborated, and that a separate specialized type was less incline to
prevent adding new attributes in the future.

> HTTP mostly deals in bytes, not characters.

We only want to support a specialized form of HTTP POST data
(x-www-form-urlencoded), which is in ASCII. This data can be passed to
the browser by creating a temporary HTML file with redirecting form.
This is the only cross browser way I found to do this, also that is the
only technique used on the web for login form, which in theory could be
faked to login anything. HTTP library are useless to open a browser
window, so that's not to be considered. The only thing you can do, is
call something like 'open-browser <url>'. Again, binary array with
length will not save you from anything here, it's all legal and simpler
with strings.

> Be aware that in the Telepathy extensions to the D-Bus XML format, names that
> are in Ugly_Case will generally be mapped to a different case convention for
> bindings. Has_Prop_UnreadMails would become ..._HAS_PROP_UNREADMAILS in
> telepathy-glib, whereas I think you actually want ..._HAS_PROP_UNREAD_MAILS,
> or (as wjt suggests) ..._SUPPORTS_UNREAD_MAILS or ..._HAS_UNREAD_MAILS.

Good point, I'll move to Will's naming then.

> 
> > Dependency are:
> > * Has_Prop_UnreadMails implies Has_Prop_UnreadMailCount
> > * Has_Prop_UnreadMails and Has_Signal_MailsReceived are exclusive
> 
> I see... so we probably can't just decompose this into two interfaces.
> Am I right in saying that there are basically four "compliance levels", then?

Right.

> 
> * UnreadMailCount (can this happen? Is it useful to UIs?)
All protocol I know so far combines this one, but yes it's useful. I'm
convinced this is useful (and I think this is the smallest subset a
respected protocol should support). As example, you could have a
floating widget on your desktop that show something like 'GMail: 4
unread messages' and when you click on it, you get a browser window that
opens the inbox folder of your Gmail account. The fact the you are told
if it's worth opening the browser and that you don't have to login is
all I need.

> * MailsReceived only (you're told about new mail but can't see anything about
>   old mail)
This is the case with Haze, until mail count get fixed. This is a very
sad level of support, but it still useful to show notification (like in
libnotify).

> * MailsReceived and UnreadMailCount (you're told about new mail but can't
>   see anything about old mail other than how many there were)
That is exactly how MSN and Yahoo works. Very common case where the IM
creator don't to go pass a certain line on duplication mail server
effort.

> * UnreadMails and UnreadMailCount (full state-recovery for unread mail)
This is what Google Talk does with GMail accounts, note that number of
mails is limited to 25.

So all 4 types may be useful, which I guess is a large enough number to
keep the capabilities and not split into multiple interface. Note that I
also need to document what URL request should be mandatory for each
type. I think the availability those should be rules and not
capabilities to make sure the interface remains usable.

> I second this. Please explain what information GTalk, MSN and libpurple
> actually give us, for instance in <tp:rationale> sections.

Ok, I'll try to add the four types to explain capabilities and will use
known protocol to give examples.

> wjt's point is that if UIs have to look at the value of the capabilities
> bitfield and decide between two different code paths, then this isn't
> really one API at all, it's two APIs sharing an interface name, and it might
> cause less confusion to represent it as such.

I see, sorry miss understood. I don't think it is the case. I think that
you have 3 UI mechanic involved, and one is shared between two
capabilities. The first is the display of 'unread mail count'. This is
'on/off' feature displayed in some sort of panel of widget. Then you
have the added_mail part of UnreadMailChange signal or the
ReceivedNewMail signal that would fire similar notification mechanism,
like libnotify. And the third is the detailed information about unread
mails, like a + button within the count widget that is enabled if that
flag is set.

> > 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.
> 
> That looks like an improvement, yes.

I also seen something called RequestComposeURL in papyon that I thought
was a good idea. Essentially it would open the web client in the mail
editor. This one would have to be part of capabilities. What do you
think of it ?  I'm thinking of a UI with a small letter and a start that
would quickly allow writing a mail. That icon could be added base on the
flag to the count panel.

> 
> Regards,
>     Simon
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy