| 66 | |
| 67 | == Open questions |
| 68 | |
| 69 | === Enumerate all styles? |
| 70 | Maybe `styles()` should be changed to enumerate the supported style / transport / realm combinations as tuples: |
| 71 | {{{#!python |
| 72 | def styles(self): |
| 73 | yield ('text/plain', 'sms', 'ticket') |
| 74 | }}} |
| 75 | |
| 76 | Advantage: This would give access to the list of all supported styles, without guessing the supported realms. For example a preferences panel could then create a ''preferred style'' selection UI, listing all supported styles. |
| 77 | |
| 78 | Disadvantage: Formatters could not implement catch-all fallbacks that e.g. claim to support all transports. But all current Announcer formatters do just this. |
| 79 | |
| 80 | Possible solutions: |
| 81 | * ''Do not allow'' formatters to support all transports. Is that actually even feasible? The formatter interface even states that it must be explicitly designed to work with a specific distributor. |
| 82 | * ''Require'' all formatters to support all transports. Remove the transports parameter. This would prevent using different formatters for different transports. (At least the return type of `format()` could then probably be defined to some standardized type.) |
| 83 | * ''Allow'' formatters to return `None` or `'*'` to support all transports. |
| 84 | * Define the interface with ''two methods''. One method with parameters as before; another method without parameters must list all supported styles for any transport or realm. |
| 85 | * Define the interface with one method, with ''optional parameters''. If the parameters are `None` the method must list all supported styles for any transport or realm. |
| 86 | |
| 87 | Similary, could some formatters want to support all realms? |
| 88 | |
| 89 | The chosen solution should be simple and easy to implement correctly by plugin authors. |