Closed Bug 1606573 Opened 6 years ago Closed 5 years ago

Need a persistent id for messages

Categories

(Thunderbird :: Add-Ons: Extensions API, defect)

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr78 wontfix)

Status:
RESOLVED FIXED
Milestone:
85 Branch
Tracking Flags:
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: standard8, Assigned: darktrojan)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 2 obsolete files)

Bug 1606573 - Allow extensions to find messages by the Message-ID header.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1606573 - Emit the Message-ID header on all MessageHeader API objects.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1606573 - Use messageKey instead of messageId when assigning IDs to API MessageHeader objects.
47 bytes, text/x-phabricator-request
Details | Review

The current message id is not persistent across restarts. That has a few issues:

  • A WebExtension can't store its own additional data alongside a message (e.g. a different type of tagging or classifying mechanism).
  • A WebExtension can't have a tab open with the contents of a particular message in, and have it survive a restart.

Since Thunderbird restores tabs, this particularly affects Thunderbird Conversations - I used to pass the uri of the message to the tab in the query parameters, and this would be restored on restart.

I can't do this with the message id, as that is no longer persistent, so I'll get a random message.

I'm not sure why it was felt that these need non-persistent Ids? I'm fine with the idea that they are not the existing uris, but there are valid cases I think where we need them persistent.

Can I get some sort of response here?

This is slightly concerning in that if we decide we need to change the message id type, that's going to be a massive change to the APIs which would hit people hard.

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(geoff)

I'm pretty sure we discussed this in one of the bugs - I would have preferred to use the (real) messageId. I don't remember why we didn't do that. Will defer to Geoff.

Flags: needinfo?(mkmelin+mozilla)

As best I can recall, the message tracker was made the way it is so the code could easily find a message it has seen before without having to look through every folder for it – which is why it stores both the message ID and folder URI of messages. The reason I didn't just use message ID as the identifier was that although message IDs are unique most of the time, this isn't always the case. (Copy a message from one folder to another and you instantly have two messages with the same message ID.) But, to be fair it doesn't even truly solve that problem as you can have two identical messages in the same folder.

I was hoping that by now that we'd have the new message database (bug 1572000) starting to take shape and that the design of it would enable a unique identifier for every message even if they are not unique messages, and O(1) lookup of messages by identifier wherever they are. For performance I think the identifier would have to be an integer so that still fits our existing model. But that hasn't started yet.

As for what to do about it now, I really don't know.

  • We could improve our existing message tracker to give it some sort of permanence. If we did that we'd have to ensure that existing saved data was transferred correctly to any future database.
  • We could extend the current object models to give the message ID as well as the existing ID that it gives.
  • We could change the current object models to give the message ID instead of the existing ID that it gives. This would change the type as mentioned above, I don't see that as too big an issue, especially with javascript being loosely typed. It'd bring back the issue of IDs not being unique but I suppose that's not too common a problem either.
  • Something else?
Flags: needinfo?(geoff)

just want to bring up the issue of sync between TB installations. Example: sync tags between two TB's with imap for those imap servers not storing tags (most don't store tags).

That would need a unique id. Even if mail copied or moved, hdrmessageID would help if I also can get account, folder, parent folder and parent parent folder of a message. In many cases, that would make it unique.

xnote++ gives another application: they allow text notes for messages and store them in files named by hdrmessageID. Those need to be stored somehow (bringing up the storage discussion for WX) and need to be synced as well. Currently, that can be done in the filesystem with sync software across the network, but if there are no file access for WX, well, as discussed elsewhere.

I think it is not that uncommon to have laptop and desktop PC and to want identical TB on both. That needs some syncing and data exchange in addition to what TB allows and can do now.

there is a use scenario to keep hdrmsgID accessible for WX (even if it is not ideal and not unique): message repair and restore.

Due to a disk problem, we lost 'a few' message bodies (eml's) in our imap server. The database list is still intact. The messages are also mostly still in TB in the local sync. They only go away if I resyncronise TB.

So I need to pull the messages from local back into imap. For that, I need the hdrmsgID.

I would like to put this back into focus. We need to have a message ID which is persistent accross restarts and across Thunderbird installations.

Can we keep the current "id" as it is but add an additional "messageId" to MessageHeader and also add a new function search(messageId) which returns an array of ids (as messageIds do not have to be uniqe)? This would be backward compatible, all the interactions would still be done with ids and only if needed it is possible to use the slower search function.

@Geoff: Is this plausible?
@Klaus & @Mark: Would that fix your issues?

For my extension it would make sense to have the ability to search for a messageID.

As there is no possibility to achieve this as of now, I started few weeks ago to implement a search filter for this on basis of the query(queryInfo), hopefully I progress over the weekend. Currently I'm implementing it in a way that you can query for hdrMessageId as a property of queryInfo, but I really like the idea of querying more header fields.

What do you think, would it make sense to have a header property within the queryInfo object? Or would it be more convenient to implement it as properties of the existing object and prefix all prop names with hdr, e.g. hdrMessageId?

I'm wondering if we want to be able to use more than just the message id. For Conversations, I've been using the msg uri so that I can get exactly the same message back after restart (this is for displaying it in a tab).

I'm wondering if we want to be able to use more than just the message id.

So we strive to implement a query for hdrMessageId and wait with further implementations until someone needs them?

For Conversations, I've been using the msg uri so that I can get exactly the same message back after restart (this is for displaying it in a tab).

But what happens, when the user has moved the message into a different folder while Thunderbird is closed? Will this cause trouble with the messageURI, or is Thunderbird still able to open the exact same mail?

I'm totally aware, that a hdrMessageId may not identify exactly one, single message. But when I query for a hdrMessageId I will get all existing copies of the message I queried for. For my extension this is exactly the required behaviour, as I'm keeping information, like notes and additional meta data, for a message and all existing copies of this message, as the messages are "the same", header fields and content wise.

I'm totally aware, that a hdrMessageId may not identify exactly one, single message.

Note that this is the reason that for my use case (Implementing Bug 1653851 in the add-on), just using the Message-ID header as the persistent ID would not work. I need a guarantee that the ID is unique.

Sorry for attaching the patch without any further comment, here's what's included.

The patch contains the capability for query for a specific hdrMessageID, which is close to unique as multiple messages may be returned, when a message is duplicated/copied within the same folder. The message content itself should be exactly the same for each message which is identified by hdrMessageID, described in RFC 5322, section 3.6.4 - Identification fields:

The "Message-ID:" field provides a unique message identifier that 
refers to a particular version of a particular message.  [...] 
A message identifier pertains to exactly one version of a particular 
message; subsequent revisions to the message each receive new 
message identifiers. [...]
Note: There are many instances when messages are "changed", but 
those changes do not constitute a new instantiation of that message, 
and therefore the message would not get a new message identifier.

If there's a need for having it even more precise, one could store the hdrMessageID and the folder where the message is stored, but this seems to be an edge case for me -- and will not identify a specific message anymore when messages are moved or copied.

We do need to think about what is best for all add-ons, not just a particular use case.

I think it would be useful to consider if we should replace the existing message id with this ID, or a combination of message id/folder - having a message id, then having to get another ID to make it persistent seems to be enforcing more work than necessary.

That said, the existing message ID is an integer rather than a screen, which makes this more difficult to change, unless we have some sort of mapping on Thunderbird's side.

If we do end up exposing hdrMessageId, then I think it should be an explicit persistent ID getter/setter rather than something that's hidden away in the message data.

If we add the Message-ID header to all messages objects, you could combine it with the already present folder information for an (almost¹) unique reference to a message. It may be useful to have the Message-ID for other reasons, and it's a low cost to add it, so maybe we should do that.

As you say Mark, we're currently using an integer as the id, and while it's probably okay to change that from a code point of view I don't think we should. If the upcoming changes to the message databases give us an integer which uniquely and persistently refers to a message, we can start using that number as the identifier.

(¹ I say almost because it's theoretically possible to have two copies of the same message in a folder. Not particularly useful or a good idea, but possible.)

On a different note, I don't think the name hdrMessageId is very WebExtensions-y. Abbreviations are usually avoided (except for id, weirdly) so headerMessageId might be better. Or perhaps just messageId which I admit could be confusing but if documented properly should be fine.

The message-ID is just one header of many. Instead of exposing it as a direct property, what do you think about a general getHeader() Method?

The Message-ID would then be retrievable via getHeader("message-id"). The header name parameter should be case-insensitive.

Alternatively, we could add a getter getHeaders, which would return an Object with all headers (header names all lowercase) found in an email and the Message-ID would be available at getHeaders["message-id"].

You can already get all the headers with (await browser.messages.getFull(id)).headers which is async, as any function accessing all the headers would need to be. Some, such as Message-ID, are available with no extra cost at the point we convert an nsIMsgHdr to a WE format, because the message database stores them.

(In reply to Geoff Lankow (:darktrojan) from comment #14)

If we add the Message-ID header to all messages objects, you could combine it with the already present folder information for an (almost¹) unique reference to a message. It may be useful to have the Message-ID for other reasons, and it's a low cost to add it, so maybe we should do that.

I assume you mean the MessageHeader objects? If so, then I think that would be reasonable. Either something like persistentId or messageId would be reasonable. I definitely think this is worth being specific about, even if it is "duplicate" data.

The only thing that's slightly weird about the folder reference, is that you'd need to store the accountId and path, but I guess we can just document that.

I'd also like to suggest that we post the final recommendation (with reasons as to why) to the list on topicbox for a week or so before we implement this, in case there are concerns from other add-on authors that we haven't thought about.

Message-ID is pretty special and I think we need the ability to get a message by that, as it's the only real reliable external reference that could be obtained. We can't control the order or other properties that may change externally, i.e. on the server.

I think we can assume that every message is unique by ID. But we still need to consider that that same message can be stored in many folders, and also many times in the same folder. Seems like the actual storage locations would be metadata the database keeps about the messages though.

For database storage, I think it should be wrong to use any integer ids from there in any external operation. Also likely the key in the db should be the string message-id. Databases will still internally convert that to a hash/number that they use for lookup so shouldn't be a problem to refer to messages by message-id for id.

Totally agree with you, Geoff. Introducing the headerMessageId as the main identifier might lead developers on the wrong direction. Having a mechanism to query for any message information, either header fields or message content, is crucial for AddOn developers. The "new" way of dealing with volatile IDs during runtime might be unfamiliar at the first glance, but in the end you're able to access the information you need. Using the headerMessageId as main message identifier might be handy by dropping one step, as you don't need the chain headerMessageId >> messageId >> message.

That said, currently AddOn developers are not able to query all header information they might need via a first level call. I suggested to have an additional header property in the queryInfo (or we prefix all header props in with header), so we can introduce query mechanisms over time (see https://bugzilla.mozilla.org/show_bug.cgi?id=1606573#c7), if it's feasible - as Geoff said, the headerMessageId is stored anyway and therefor cheap and easy to use. Other fields may be implemented as a query in the future, e.g. when the indexing engine got a refresh or there's an urgent need for having more fields available, but for now I think the headerMessageId will be a good fit for AddOn devs to identify messages.

Currently the solution for "querying" (which is more filtering) messages based on header fields is to iterate over all messages and get the header fields for each message.

Using headerMessageId as message identifier is sufficient, as it is guaranteed that you get the same message instances(!) when using this id. If it is needed that a single message in a specific folder needs to be identified, then we need to generate kind of a persistable ID. Just handing out the primary key from the message database will not work, as the persistent IDs might be stored externally and synced to other Thunderbird instances on other computers. The only reliable identifier here is, and ever was, the headerMessageId.

Attachment #9183043 - Flags: review?(mkmelin+mozilla) → review?(geoff)

According to the not very webextension-y naming the property hdrMessageId was renamed to headerMessageId.

Attachment #9183043 - Attachment is obsolete: true
Attachment #9183043 - Flags: review?(geoff)
Attachment #9183124 - Flags: review?(geoff)

(In reply to Arnd Issler from comment #20)

That said, currently AddOn developers are not able to query all header information they might need via a first level call. I suggested to have an additional header property in the queryInfo (or we prefix all header props in with header), so we can introduce query mechanisms over time (see https://bugzilla.mozilla.org/show_bug.cgi?id=1606573#c7)...

I don't think anyone has been calling into question the need for a queryInfo option. I have been saying that if we add that option, we should also make getting the header ID (or whatever is going to be persistent for now) easier at the same time. This is for two reasons: 1) visibility as to how you can get something that's more persistent - we need to be explicit 2) you shouldn't have to be loading the full message to get that information.

(In reply to Geoff Lankow (:darktrojan) from comment #14)

If we add the Message-ID header to all messages objects, you could combine it with the already present folder information for an (almost¹) unique reference to a message. It may be useful to have the Message-ID for other reasons, and it's a low cost to add it, so maybe we should do that.

(¹ I say almost because it's theoretically possible to have two copies of the same message in a folder. Not particularly useful or a good idea, but possible.)

It isn't just theoretical; it is very simple to create a situation with identical message ids in the same folder. I don't think this can or should be ignored in the design. If the message-id query returns an array of all matches, per folder, that should do it.

There are already failures to handle non uniqueness of messages in the codebase:

  1. Gloda design assumes unique message-id and will not index copies; a search will only ever find 1 matching message despite the presence of others.
  2. The view code still has methods that only consider a message by index (order received) only -- and not folder -- so that operations fail to get the right message in cross folder situations.

Let's not repeat that.

Let me repeat myself, this time a little more verbose:

Using the Message-ID header as ID would not be enough for my use case, which is caching the result of the DKIM verification my add-ons does. Combining it with the folder would not help.

It is actually quite easy to get two (similar but different) messages with the same Message-ID. Just think if someone uses reply all on a message list. Then the sender of the replied too message would get two e-mails, (a) for his personal e-mail, and (b) via the mailing list.
And the mailing list could change the e-mail, by e.g. adding the very common mailings list footer. Which would break the DKIM signature of the e-mail.
So the user would now have two mails, (a) with a valid DKIM signature, and (b) with an invalid signature, both having the same Message-ID.

Another problem, although admittedly probably very special for my use case, is that the Message-ID is under control of the sender. If an attacker somehow got the information (or guessed) that the user received an e-mail from e.g. PayPal with the Message-ID of <12345.67890@paypal.com>, he could send his own mail using the same Message-ID.
Which would, with caching enabled, result in my add-on incorrectly showing a valid DKIM signature from PayPal for the attackers e-mail. This of course would be quite bad.

Just handing out the primary key from the message database will not work, as the persistent IDs might be stored externally and synced to other Thunderbird instances on other computers.

This would not be a problem for my use case. I do not need an ID that identifies a message across TB instances, or even outside of TB. For that I agree, there probably is nothing better than the already existing Message-ID.

(In reply to plieser from comment #24)

It is actually quite easy to get two (similar but different) messages with the same Message-ID. Just think if someone uses reply all on a message list. Then the sender of the replied too message would get two e-mails, (a) for his personal e-mail, and (b) via the mailing list.

Well those mails would have different Message-IDs. Mailing list software changes it to their own before they send the list message to people.

for the user, two emails with the same hdrMessageId can be different, being in one or several folders, because:
*** tags, stars, etc. We allow the user to 'work' on messages, also convert to tasks or events etc.

In one folder, I can tag it important (in my 'friends' folder), in another, I can tag it private (in inbox) . Just as an example.

In my use case, I need the hdrMessageId and the folder localtion. What happens with uri if the message is moved in imap in another TB installation?

I opt to have a header info available without querying. Again, imap can download headers only, and that would help faster access. It should be access to all headers, if possible.
Anyway, by rfc, hdrMessageId is the currrent primary unique id, so it should be top level.

On a byside, I would prefer not to rename all the old variables. We know what a hdrMessageId is. headerMessageId might do as well, but if we use messageIds or similiar: is it an integer, an uri, a hdrMessageId, or what? Renaming creates unclarity. It actually is the main id in the header, and can be viewed in the full email source from the main menu, so why rename?

(In reply to Magnus Melin [:mkmelin] from comment #25)

(In reply to plieser from comment #24)

It is actually quite easy to get two (similar but different) messages with the same Message-ID. Just think if someone uses reply all on a message list. Then the sender of the replied too message would get two e-mails, (a) for his personal e-mail, and (b) via the mailing list.

Well those mails would have different Message-IDs. Mailing list software changes it to their own before they send the list message to people.

Just checked, and this doesn't seem to be the case for the addons@thunderbird.topicbox.com or tb-planning@mozilla.org list. But must admit I'm not an expert on this, so maybe I'm missing something.

Anyway, as there should still be other ways you could get e-mails with the same Message-ID header (although probably not that common), I don't thing relaying on the Message-ID for an unique ID for the extensions APIs would be a good idea, regardless of the common behavior of malign lists.

Ah, you're right, seems the id is kept.

Plieser wrote:

[...] I don't thing relaying on the Message-ID for an unique ID for the extensions APIs would be a good idea [...]

For most use cases it is the primary identifier which should ensure, that the message is the same for each occurrence within your mailbox. The headers may change, this doesn't need to lead to a new message ID. When working with message IDs, you need to be aware of this, and for you (as well as others) the use case might not fit. For a "normal use case" two messages with the same message ID are considered as "identical", as the message ID should be unique by design. If you receive a second email with a "guessed" fake message ID, your MTA should deny the second message, as a message with the same ID already exist.

But I understand that this doesn't fit your needs, Philippe, as you're addressing sensitive information with your AddOn and therefore need to be sure, that the message you're displaying additional information for is the one when you first calculated the verified domain key for the message. Maybe a combination of the following will work for you:

  1. use the IMAP UID as main identifier, as it is truly unique
  2. for non-IMAP messages, calculate a hash from key headers and store it along the message ID. When a message is displayed, get the message ID and calculate the hash, then query your database for a match of hash & message ID
  3. do not persist the verfication result. Currently, you're storing the information in an SQLite database and query for a already verified result when displaying a message. Maybe it's a more robust solution when you verify the domain key when the message is displayed (I don't know how you handle revoked DKIMs, maybe this is an issue)
  4. why not use the DKIM Signature directly as the main identifier?

Back to the messageHeaderId:

  1. not being able to get all occurrences of a message by its message ID is a pretty unsatisfying situation. Shall we "fix" this here and return an array of all messageIds so one can iterate over them to reach every single message?
  2. one shouldn't rely on the data type of the volatile messageId, as it has no meaning. There's no order, no operations, it is just an identifier which you can use. As a developer I don't care if it is an emoji or image data or a good old integer. Handing a volatile ID out to the AddOn developers was maybe a glitch in the API design as it seems for now, since there is some confusion about this, but hey, we can deal with it. It just works when you know how to handle it.
  3. naming is hard, and renaming is even harder. Unfortunately, messageId is already spread into the wild and is well documented, and hdrMessageId maybe never was a good name, but well known for AddOn developers who are in the game for for years. So yes, I feel familiar with the name, but it is time to let it go and find a good match for all of us.

I think there may be a miss understanding. Although I don't need it, I agree with you that it would be good to have a method to query for a list of message that have a specific Message-ID header. And one could also consider adding it to the MessageHeader for easier access.

But independent of the needs for my add-on, I don't think it would be good to replace the current (non persistent, but unique for the current run of TB) messageId number, that is used in various extension APIs, with the Message-ID. Or anything else there TB can not guarantee the uniqueness, at least for the current run of TB.
Which I got the impression some of you suggested, but could also be that I just misunderstood it.

Just consider when you want to delete a specific e-mail with messages.delete(messageIds, [skipTrash]). If the ID provided there could potentially reference multiple messages, which one should be deleted?
Same problem for retrieving the complete contend via messages.getRaw(messageId), and probably many other places there the messageId number is currently used in the API.

Maybe it would make sense to split the bug.

(In reply to Arnd Issler from comment #29)

Back to the messageHeaderId:

  1. not being able to get all occurrences of a message by its message ID is a pretty unsatisfying situation. Shall we "fix" this here and return an array of all messageIds so one can iterate over them to reach every single message?

I don't understand this comment. messages.query already returns an array. I would therefore expect any query to return all of them, and be scoped to folder or whatever if those additional options were supplied.

  1. one shouldn't rely on the data type of the volatile messageId, as it has no meaning. There's no order, no operations, it is just an identifier which you can use. As a developer I don't care if it is an emoji or image data or a good old integer. Handing a volatile ID out to the AddOn developers was maybe a glitch in the API design as it seems for now, since there is some confusion about this, but hey, we can deal with it. It just works when you know how to handle it.

Whilst this is the case, it has already been defined to be an integer. Changing that needs careful consideration - whilst it is probably true that most people don't care what it was, and with JavaScript it probably doesn't matter too much, what about people using typescript or if someone has done some sort of type dependent check on it? The API is intended to be stable over time, and this would be breaking that.

(In reply to Mark Banner (:standard8) (afk until 26 Oct) from comment #31)

(In reply to Arnd Issler from comment #29)

Back to the messageHeaderId:

  1. not being able to get all occurrences of a message by its message ID is a pretty unsatisfying situation. Shall we "fix" this here and return an array of all messageIds so one can iterate over them to reach every single message?

I don't understand this comment. messages.query already returns an array. I would therefore expect any query to return all of them, and be scoped to folder or whatever if those additional options were supplied.

My bad, sorry for the confusion. The starting point was this point alta 88 wrote in their post (comment #23):

Gloda design assumes unique message-id and will not index copies; a search will only ever find 1 matching message despite the presence of others.

As I read this I thought that one is only able to get the first message when you query for the header Message ID, and I haven't checked it - now as I have checked it against the current build (and my patch applied) the behavior is as follows:

Assume an inbox:

[Flagged] [Subject] [Message-ID]
Baz msg.0@bar.example
⭐️ Foo foo@bar.example
Foo foo@bar.example

Example No. 1:

const list = browser.messages.query({ headerMessageId: 'foo@bar.example' });
console.log(list.messages.map(msg => msg.id));   // [1, 1]

The query results in an array containing two identical messageIds.

Example No. 2:

const list = browser.messages.query({ headerMessageId: 'foo@bar.example' });
console.log(list.messages.map(msg => ({id: msg.id, flagged: msg.flagged})));   // [{ id: 1, flagged: true }, { id: 1, flagged: false }]

The query result contains two objects: [ { id: 1, flagged: true }, { id: 1, flagged: false } ].

When updating the message properties by using browser.messages.update(1, { flagged: false }); I would expect Thunderbird to mark both messages as flagged, but regardless which property was modified, only the last message is updated. So one is able to query for all messages, but operations like copy/move or applying properties to all messages is not possible. This seems to be a bug?

(In reply to Mark Banner (:standard8) (afk until 26 Oct) from comment #31)

Whilst this is the case, it has already been defined to be an integer. Changing that needs careful consideration - whilst it is probably true that most people don't care what it was, and with JavaScript it probably doesn't matter too much, what about people using typescript or if someone has done some sort of type dependent check on it? The API is intended to be stable over time, and this would be breaking that.

Absolutely true and valid. That was not the point I wanted to address. All I wanted to say was the fact, that for several types of information one tend to see deeper meaning behind it. Example: when a primary key is an integer/number, one should think that lower primary keys are referring to older datasets as higher primary keys. While this might be true (and often is), it is not guaranteed nor intended. But humans often assume that there's an "order" when they see numbers.
I totally agree that we shouldn't change this, as it is released to the public and documented. No need to change the data type.

considering that messages can be tagged and moved, can we have a persistent id that allows to identify a message after being moved?
In the example above, we know that there are two foo's, but do we know which is which after a folder move? That might concen imap, only.

(In reply to klaus from comment #33)

considering that messages can be tagged and moved, can we have a persistent id that allows to identify a message after being moved?
In the example above, we know that there are two foo's, but do we know which is which after a folder move? That might concen imap, only.

That's the point which might be a bug here: they both have the same messageId, so I assume that both of them will be moved or updated. But right now there's no web-extension-y way for doing this and IMHO the messages should have a different messageId.

The workaround is to query before and after move and check the properties of each message with identical messageIds. If there's no difference in the props, the mails are "kind of the same" and it doesn't matter which one is moved/copied/updated.

"... an array of all matches, per folder, that should do it" assumes the array items will contain some unique identifier to a specific message which may not have a unique message-id. The identifier would be used in subsequent operations. Otherwise the the api is not complete/useful.

Is using nsIMsgDBHdr.messageKey (and given the folder uri) to achieve a unique reference too easy a solution?

(In reply to alta88 from comment #35)

Is using nsIMsgDBHdr.messageKey (and given the folder uri) to achieve a unique reference too easy a solution?

If we use it instead of messageId, we can reference individual copies of the same message in a folder, that works. I've got a patch to do that which I'll post shortly in another bug, since it's not really what we're aiming for in this bug.

I'd love to be able to use it as part of a persistent ID and solve this bug too, and it would almost work, but I'm told that when certain changes happen to folders, the message keys aren't necessarily what they were before.

So here's what we can do (and I intend to do):

  • Take arnd's patch for querying by message ID.
  • Add the message ID to all MessageHeader objects emitted by APIs.
  • Use the messageKey instead of the messageID when working out if a message is unique (for giving it a WE id value).

It's not perfect but it will get us a lot closer to the aim of this bug. Bug 1572000 is on the roadmap for next year, which should enable a truly persistent ID, but it remains to be seen if that will happen before the next release.

This will allow extensions to individually identify each copy of a message in a folder.

Depends on D98568

Comment on attachment 9183124 [details] [diff] [review]
Add capability to query a specific headerMessageId via extension API

I'm approving this review, but also obsoleting the patch as I've just pushed an updated one to Phabricator.

Attachment #9183124 - Attachment is obsolete: true
Attachment #9183124 - Flags: review?(geoff)
Assignee: nobody → geoff
Status: NEW → ASSIGNED

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/eb24cf9e6368
Allow extensions to find messages by the Message-ID header. r=darktrojan,john.bieling
https://hg.mozilla.org/comm-central/rev/abdd53059522
Emit the Message-ID header on all MessageHeader API objects. r=john.bieling
https://hg.mozilla.org/comm-central/rev/203292b50ef3
Use messageKey instead of messageId when assigning IDs to API MessageHeader objects. r=john.bieling

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

This bug got sidetracked, so I'm going to create a clone of it to deal with the original issue which remains unresolved.

Blocks: 1680608
Target Milestone: --- → 85 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: