Message composition WebExtensions API
Categories
(Thunderbird :: Add-Ons: Extensions API, enhancement)
Tracking
(Not tracked)
People
(Reporter: darktrojan, Assigned: darktrojan)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
11.21 KB,
patch
|
mkmelin
:
review+
|
Details | Diff | Splinter Review |
We'll need a way to open the compose window, and specify recipients, references (is this a reply or forward), attachments, etc.
Assignee | ||
Comment 1•5 years ago
|
||
Here's the API I have in mind: https://thunderbird-webextensions.readthedocs.io/en/latest/compose.html
Assignee | ||
Comment 2•5 years ago
|
||
I thought I'd posted this an age ago. Apparently I did not.
Comment 3•5 years ago
|
||
Comment on attachment 9033916 [details] [diff] [review] 1503423-webext-compose-1.diff Review of attachment 9033916 [details] [diff] [review]: ----------------------------------------------------------------- Apart from the comments, I suppose this is ok. r=mkmelin ::: mail/components/extensions/schemas/compose.json @@ +2,5 @@ > + { > + "namespace": "compose", > + "types": [ > + { > + "id": "ComposeRecipient", We should reuse some existing terminology here. I think this is called "address" in the rfc 5322 spec. Although slightly confusing, that still sounds like the best option. @@ +88,5 @@ > + "parameters": [ > + { > + "name": "messageId", > + "description": "The message to reply to", > + "type": "integer", I don't like the messgageId stuff at all. But it should at least be named something less confusing. messageTrackerId perhaps? @@ +110,5 @@ > + "async": true, > + "parameters": [ > + { > + "name": "messageId", > + "description": "The message to reply to", to forward
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #3)
Comment on attachment 9033916 [details] [diff] [review]
1503423-webext-compose-1.diffReview of attachment 9033916 [details] [diff] [review]:
Apart from the comments, I suppose this is ok. r=mkmelin
::: mail/components/extensions/schemas/compose.json
@@ +2,5 @@
- {
- "namespace": "compose",
- "types": [
{
"id": "ComposeRecipient",
We should reuse some existing terminology here.
I think this is called "address" in the rfc 5322 spec. Although slightly
confusing, that still sounds like the best option.
Yes, but it's not an RFC5322 recipient. It could be, but it also could be an address book entry.
@@ +88,5 @@
"parameters": [
{
"name": "messageId",
"description": "The message to reply to",
"type": "integer",
I don't like the messgageId stuff at all. But it should at least be named
something less confusing. messageTrackerId perhaps?
It's called messageId throughout the messages API. I called it that because it's an identifier of a message. To call it messageTrackerId gives some information about where it came from, which is totally irrelevant, and if we later decide to change how that works, wrong.
Comment 5•5 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #4)
I think this is called "address" in the rfc 5322 spec. Although slightly
confusing, that still sounds like the best option.Yes, but it's not an RFC5322 recipient. It could be, but it also could be
an address book entry.
Right, I assume you mean mailingList entry. Which is a very Thunderbird specific thing.
Not sure if we want to keep supporting that indefinitely. It has it's usecases but a tagged contacts based approach would be more sane for most things.
Maybe instead of defining the parameters to be ComposeRecipient ou want to declare the parameter type to be of either address or mailinglist type?
Another option would be to require the caller to expand the mailinglist before calling this api, and only really allow addresses.
It's called messageId throughout the messages API. I called it that because
it's an identifier of a message. To call it messageTrackerId gives some
information about where it came from, which is totally irrelevant, and if we
later decide to change how that works, wrong.
But it is correctly identifying what it refers to, no? The id is a tracker internal thing.
If not messageTrackerId, perhaps messageIdentifier?
Assignee | ||
Comment 6•5 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #5)
(In reply to Geoff Lankow (:darktrojan) from comment #4)
I think this is called "address" in the rfc 5322 spec. Although slightly
confusing, that still sounds like the best option.Yes, but it's not an RFC5322 recipient. It could be, but it also could be
an address book entry.Right, I assume you mean mailingList entry. Which is a very Thunderbird specific thing.
Not sure if we want to keep supporting that indefinitely. It has it's usecases but a tagged contacts based approach would be more sane for most things.
Or a contact.
Maybe instead of defining the parameters to be ComposeRecipient ou want to declare the parameter type to be of either address or mailinglist type?
That's exactly what it does. By making a type named ComposeRecipient all I'm doing is avoiding the repetition of that choice three times.
It's called messageId throughout the messages API. I called it that because
it's an identifier of a message. To call it messageTrackerId gives some
information about where it came from, which is totally irrelevant, and if we
later decide to change how that works, wrong.But it is correctly identifying what it refers to, no? The id is a tracker internal thing.
If not messageTrackerId, perhaps messageIdentifier?
What do you think messageId is a shortened form of?
Comment 7•5 years ago
|
||
Feel free to find something better I just don't want it confused with Message-ID when it's not.
Assignee | ||
Comment 8•5 years ago
|
||
Can I just document that they're not the same thing? It's only the name of function argument after all.
Comment 9•5 years ago
|
||
I suppose.
Comment 10•5 years ago
|
||
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/71731d521397
Message composition WebExtensions API; r=mkmelin DONTBUILD
Assignee | ||
Updated•5 years ago
|
Description
•