1882574 - Refactor outgoing message server support

Status: RESOLVED FIXED

(Thunderbird :: General, task)

Description

[Brendan Abolivier [:babolivier]]

Thunderbird's code dealing with outgoing servers is built around the fact that the only outgoing server type is SMTP. In order to support EWS in Thunderbird, we need to make the related interfaces more generic, in order to build a EWS-specific implementation.

Comment 1

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1882574 - Enable outgoing message servers other than SMTP. r=#thunderbird-reviewers

There are a few steps remaining before this patch is ready for review:

• Remove assumptions that the outgoing server is implemented in JavaScript
• Audit the nsIMsgOutgoingServer interface to see what more can be decluttered and generalised

Eventually we'll also want to migrate the prefs so they don't use "smtp" in their names if the server doesn't actually use SMTP, but that will likely come in a second step.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fa1090b30f09
Enable outgoing message servers other than SMTP. r=leftmostcat

Comment 3

[Yury]

Drive-by comment: Why did you introduce AUTF8String getPasswordWithUI(in AUTF8String promptString, in AUTF8String promptTitle);
https://hg.mozilla.org/comm-central/rev/fa1090b30f09ec14a166cd03fc2e8148f0ca9975#l47.209
when the incoming side has AString getPasswordWithUI(in AString aPromptString, in AString aPromptTitle);, see:
https://searchfox.org/comm-central/rev/ab3823fb293b4457b8e747b4b661bd59520cd314/mailnews/base/public/nsIMsgIncomingServer.idl#130

Using an UTF-16 API will save UTF-8 to UTF-16 and vice versa conversations at runtime since native JS strings are UTF-16, but would be passed through the API as UTF-8. Or am I missing something?

Comment 4

[Brendan Abolivier [:babolivier]]

There is no guarantee that a future implementation of this class will be in JavaScript, and in fact this is pretty much prep work to support an initial version of sending emails via EWS using a Rust implementation. Therefore we need to have some form of guarantee that, when crossing over the XPC boundary, the strings will use the correct encoding and highest level of compatibility, without putting the burden on the non-JS implementation (or its platform-specific bindings) or its non-JS consumers.

In Rust, wstring is represented as *const i16, which is as far from idiomatic as you can imagine; and AString means any operation, even one that doesn't cross the XPC boundary, triggers a UTF-8 <-> UTF-16 conversion. AUTF8String provides a satisfying guarantee in that regard, without having to convert over-eagerly (since the conversion only happens across the boundary, when it's necessary), or place the code generating or using these strings in charge of converting for a different platform.

I agree that it's not ideal to create a divergence with the incoming side, but imo this should be fixed by updating the incoming interface.

Comment 5

[Yury]

and AString means any operation, even one that doesn't cross the XPC boundary, triggers a UTF-8 <-> UTF-16 conversion.

Thanks for the information. But the line above applies to Rust, not JS, correct? So Rust doesn't have a "native" char16_t-based string type? Looks like there is a utf16string crate providing WString, etc.

Comment 6

[Brendan Abolivier [:babolivier]]

(In reply to Yury from comment #5)

and AString means any operation, even one that doesn't cross the XPC boundary, triggers a UTF-8 <-> UTF-16 conversion.

Thanks for the information. But the line above applies to Rust, not JS, correct?

Rust and C++, but not JS, correct.

So Rust doesn't have a "native" char16_t-based string type? Looks like there is a utf16string crate providing WString, etc.

Sure, but since the native string encoding is UTF-8, you'd still end up with the same issue as using AString, meaning every time you need to instantiate, manipulate, or output the string, you'd still be converting.

Generally speaking, AUTF8String allows us to use idiomatic string encoding in all three languages that make up Thunderbird (UTF8 in C++ and Rust, UTF16 in JS), and with a minimal amount of conversions while providing a guarantee that conversions happen when they're needed. So I see using it as an improvement for any interface which implementations are expected to go anywhere near JS (including its consumers).

Comment 7

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1882574 - Follow-up: fix a missing call site for initFromOutgoing. r=#thunderbird-reviewers

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f761e605e19a
Follow-up: fix a missing call site for initFromOutgoing. r=leftmostcat

Comment 9

[Wayne Mery (:wsmwk)]

Attached file Bug 1882574 - Follow-up: fix a missing call site for initFromOutgoing. r=#thunderbird-reviewers — Details

My issue is fixed in today's daily. Thanks!

Comment 10

[Brendan Abolivier [:babolivier]]

Great, thanks for flagging it Wayne!