[Bug 13349] Undraft mail notification spec

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|                            |undraft?

--- Comment #30 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-19 07:21:42 PDT ---
(In reply to comment #29)
> (In reply to comment #28)
> > Bug #27167 seems a little subtle
[...]
> The solution you proposed (to suspend async
> calls until dependent calls has complete) is the right solution.

I've asked for minor (documentation etc.) changes to the branch in Bug #27167,
but I think the approach is now correct, so this isn't a blocker.

> Currently only MyZone has UI for it. It's a bit of work to do all the
> account/connection monitoring but when the MailNotification interface is
> reached it's quite straightforward to update UI with it.

That's encouraging!

I think undrafting this can go on the spec-meeting agenda, although there are a
couple of remaining issues.

The Subscribe() and Unsubscribe() methods are rather generically named, and
collisions with similar methods on other interfaces are likely. In Bug #21787 I
added an Unsubscribe() method for presence subscriptions, which I think should
"win" (i.e. be the one that keeps the name) if necessary. So, the question here
is: do we care about bindings that can't use colliding methods?

In particular, in dbus-python it's hard, although possible, to implement
colliding methods - you have to have them in different subclasses, or mixins,
or something.

I believe most/all *client* bindings are happy enough to *call* two methods of
the same name, though?

(In reply to comment #27)
> Nicolas pointed out on the bug for the Gabble implementation that the display
> name in a Mail_Address can be empty. If this is the intention, the spec should
> explicitly say so, to remind client authors that they might need to fall back
> to displaying the email address.

As far as I can see, it still doesn't.

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