1949436 - Remove nsIMsgFolder.folderURL

Status: RESOLVED FIXED

(MailNews Core :: Backend, task)

Description

[Brendan Abolivier [:babolivier]]

Currently, there are two ways for a folder to expose a URI or URL: either via nsIMsgFolder.URI or nsIMsgFolder.folderURL. This is confusing and needlessly expends the API surface for folders classes.

As far as I can tell, the only case in which these two attributes differ is for local folders. IMAP uses the same value for both attributes, and although EWS doesn't support folderURL yet (bug 1917597) it would end up doing the same. I haven't been able to test NNTP/news as extensively as I have for the other folder types, but from looking at the code, it looks to be roughly the case too.

Looking at Searchfox:

• URI gets over 500 hits between JS and C++
• folderURL gets less than 20 hits between JS and C++. All of these occurrences seem to be using the attribute's value for logging or labelling, or other operations that don't involve actually processing (e.g. parsing) the value (as far as I can tell)

Therefore, I think we should remove nsIMsgFolder.folderURL, and change the places that use it to use nsIMsgFolder.URI instead, since it shouldn't make a difference which one they use. I also think this would make the affected log lines more accessible since they'll include the same URI that's actually used by the rest of the code.

I also ran a try run earlier today that seems to show removing folderURL and replacing it with URI does not seem to break anything.

Comment 1

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1949436 - Remove nsIMsgFolder.folderURL. r=#thunderbird-reviewers

Comment 2

[Ben Campbell]

Why do local folders diverge these values?
Is it some attempt at sanitisation to let the path be used as filesystem path?

Comment 3

[Brendan Abolivier [:babolivier]]

(In reply to Ben Campbell from comment #2)

Why do local folders diverge these values?
Is it some attempt at sanitisation to let the path be used as filesystem path?

It's difficult to tell, considering we don't seem to do anything specific with it at the moment. I assume there might have been an intent to standardise folder URLs one way or another and do more with them than just labelling/logging, or to special-case local folder URLs for some use, but that's currently not the case. Both URI and folderURL (and their implementations) date back from before the move to Mercurial, so it's not trivial to browse back to their inception and understand the original intent.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2be02a22ef3c
Remove nsIMsgFolder.folderURL. r=mkmelin