[Telepathy] Spec meeting notes on Mail Notification interface

[Simon McVittie]

On Thu, 21 Jan 2010 at 10:58:34 -0500, Nicolas Dufresne wrote:
> 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?).

In general, forbidding something from happening more than once per process
makes life difficult for anyone with a plugin architecture; plugins can't
know whether other plugins already did the one-per-process action. Use case:

* I have a process with plugins, all of which share a unique name (e.g. all
  my plugins use dbus-glib, or all of them use QtDBus), like the Maemo 5
  status menu
* I install two mail notification plugins - written by different people,
  perhaps - to see which one I want to keep using and which one I want to
  discard
* They both subscribe; neither should get an error
* I decide one of them is better and uninstall the other one, causing the
  plugin to be unloaded
* The remaining plugin should still be subscribed

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

I see. If that's the case, why don't you just put it in a single string?

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

Please add this to the <tp:rationale> for the representation of the POST
data (we don't have specific markup for implementation notes at the moment :-)

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

Good idea. RequestInboxURL and RequestMailURL should also have capability
flags; in practice we only care about webmail systems at the moment, but
I can see that we might well want to support being told about new mail that's
only available from IMAP or a proprietary protocol (MS Office Communications
Server? Sametime? etc.) in later implementations.

Regards,
    Simon