Closed Bug 1503423 Opened 6 years ago Closed 5 years ago

Message composition WebExtensions API

Categories

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

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 67.0

People

(Reporter: darktrojan, Assigned: darktrojan)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

We'll need a way to open the compose window, and specify recipients, references (is this a reply or forward), attachments, etc.
Depends on: 1513824
I thought I'd posted this an age ago. Apparently I did not.
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #9033916 - Flags: review?(mkmelin+mozilla)
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
Attachment #9033916 - Flags: review?(mkmelin+mozilla) → review+

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

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.

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.

(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?

(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?

Feel free to find something better I just don't want it confused with Message-ID when it's not.

Can I just document that they're not the same thing? It's only the name of function argument after all.

I suppose.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/71731d521397
Message composition WebExtensions API; r=mkmelin DONTBUILD

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 67.0
You need to log in before you can comment on or make changes to this bug.