Changes between Version 3 and Version 4 of TracDev/Proposals/AdvancedNotification/IEmailAddressResolver

Timestamp:

Oct 14, 2013, 9:02:29 PM (11 years ago)

Author:

Peter Suter

Comment:

Raise some questions about the proposed interface.

TracDev/Proposals/AdvancedNotification/IEmailAddressResolver

@@ -11 +11 @@
 
 Now plugins can add additional ways to find an email address for a Trac session that has no email address specified in the user preferences.
-
-OPEN Is this even needed? The email distributor could just contain this logic. Maybe for directory services?
 
 == Usage ==
@@ -56 +54 @@
 Only `trac.ticket.notification.mail.DefaultDomainEmailResolver` and `trac.ticket.notification.mail.SessionEmailResolver`  are part of core Trac.
 
-OPEN Are they even needed? The email distributor could just contain this logic.
-
 Various other resolvers might be part of th:AnnouncerPlugin.
 
@@ -67 +63 @@
    * DONE Renamed `get_address_for_name()` to `get_address_for_session()`.
    * DONE Other distributors can not use the same interface (according to comment in th:AnnouncerPlugin's `XmppDistributor`) so this is email specific.
-   * TODO: Make it usable by distributors other than email?
+
+ * Related tickets:
+   * #2766 introduced the `ignore_domains` option after so user names that look like email addresses are recognized correctly.
+   * #4372 introduced the `admit_domains` option so email addresses with uncommon domains are recognized correctly.
+
+== Open Questions
+
+=== Integrate in email distributor?
+
+Is this even needed? The email distributor could just contain this logic directly.
+
+Counter-arguments:
+* Plugins that for example integrate Trac with an external directory services could automatically retrieve a users email address from there using this interface.
+* See next question.
+
+=== Support extendible email address recognition?
+
+Categorizing CC field entries as email addresses or session ids is surprisingly complex. In Trac various configuration options have already been added to help some corner cases (e.g. `admit_domains`, `ignore_domains`, `use_short_addr`). In the future, similar problems should be solvable by writing a simple plugin implementing this interface.
+
+Would this work with the current approach? It seems this logic would have to be executed in an earlier stage. When parsing a CC field a [wiki:TracDev/Proposals/AdvancedNotification/INotificationSubscriber subscriber] creates `session` and `authenticated` or `address` values. The IEmailAddressResolver is only invoked later, on `session` and `authenticated`.
+
+=== Support distributors other than email?
+
+Should this work with distributors other than email? Is email a special case? Because it is inherently complex? Or because there are complex compatibility issues with usage of raw email addresses in ticket fields? Or should other distributors support raw addresses too? How would these be recognized / differentiated? (XMPP addresses look similar to email addresses.)
+
+Would a resolver have to know the preferred transport of a session to decide if the preferred email or XMPP address should be yielded? Or would there be separate !OrderedExtensionsOptions (e.g. `email_address_resolvers` and `xmpp_address_resolvers`) in the respective distributors?