[graph] Add manual configuration of Exchange sub-protocol
Categories
(MailNews Core :: Networking: Exchange, task, P2)
Tracking
(Not tracked)
People
(Reporter: edicharry, Assigned: edicharry)
References
(Blocks 1 open bug)
Details
(Keywords: leave-open)
Attachments
(3 files)
Add a configuration option that will enable the use of EWS or Graph API by the existing EWS implementation. Allow the manual configuration of the API endpoint to use when Graph is selected. The ability to do this should be hidden behind a pref that enables/disables the option to use Graph API for Exchange.
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Updated•13 days ago
|
Comment 1•13 days ago
•
|
||
We've been through this with Owl, which supports 3 Exchange protocols, and eventually it's easier to keep these protocols clearly separate. It makes a whole lot simpler later on:
- Server type implementation
- Account initialization on startup
- Manual config
- Automatic config using AutoConfig.
Otherwise, you'll need to add extra code and special cases everywhere. But when they are separate protocols, it just works out of the box and you just need to add an extra protocol entry.
In the AutoConfig spec, the Graph and EWS protocols are expressed as separate protocols as well, see protocol type definition, XML example, and real-world Office365 example.
In case it helps your decision: Both EWS and Graph protocols are not limited to Microsoft Exchange/Office365 servers, but a number of other mail servers support one or both of them, e.g. Zimbra and Amazon WorkMail support EWS, and Kopano supports Graph and EWS. So, arguably, both are separate protocols in their own right.
Please treat Graph as a top-level protocol in Thunderbird, on the same level as IMAP, POP3 and EWS, not as a sub-form below EWS. Specifically, the "server type" should say "graph", not "ews".
Comment 2•13 days ago
•
|
||
As a side effect, keeping the server type implementations separate will force a cleaner API design as well, which makes the addition of new protocols easier. If you share code between EWS and Graph with normal programming techniques (crates, libraries, subclasses, functions, whatever fits), which will then also benefit future protocol implementations.
| Assignee | ||
Comment 3•8 days ago
|
||
| Assignee | ||
Comment 4•7 days ago
|
||
| Assignee | ||
Comment 5•6 days ago
|
||
This commit also refactors the Exchange auth implementation into the shared
protocol crate for reuse across Graph and EWS.
Updated•6 days ago
|
| Assignee | ||
Updated•4 days ago
|
Pushed by benc@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/c10366f3385d
Add new rust crate for ews/graph shared components. r=jtracey
| Assignee | ||
Comment 7•3 days ago
|
||
Forgot to mark this as leave-open
| Assignee | ||
Updated•19 hours ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/320f7f6618b2
Implement Graph client initialization. r=jtracey
Description
•