MailExtension APIs for calendar / lightning

[NeilRashbrook]

I've been trying to write a calendar provider implementation using the draft experiment. Here are my experiences so far:

• When Thunderbird shuts down, all of the extension calendars get deregistered, and the composite calendar hides them from the view. When it starts up again, the calendars get registered before the composite calendar has been created, so they stay hidden. I assume it would be better to avoid the deregistration, but failing that, defaulting to showing the calendar would be preferable.
• The calendar provider currently clears the calendar's cache on shutdown, without advising the extension, but I assume this is unintentional anyway?
• Although the options parameter to the provider listeners is described as optional, it currently needs at least an empty object. The code in convertItem is also checking the wrong property; it should be options?.returnFormat instead of options.format.
• Getting a cached calendar itself doesn't actually work, although the code tries. (I wanted to do this because I wanted a convenient way of getting all of the metadata, but see below.)
• The calendar provider currently tracks the metadata using the item's hashid, but the storage providers actually expect it to use the item's id.
• You can't update an event's date and time because the update code doesn't provide the item type to propsToItem.
• The documentation suggests that the supported values for categories are -1 (any), 0 (none), 1 (single), >1 (many). However the actual values working are 0 (none), 1 (single), >1 (any/many); -1 is treated as equal to 1.
• The provider item removal notification forgets to wrap the item. (I believe you'd rather not pass the item, but I'd still like to access its metadata at this point, but see below.)
• When the extension creates the calendar, it gets associated with the profile's default identity, which will become unhelpful in the future when you want to support meetings and invitations.

I can write PRs for some of these at some point if you don't get there first.

Lightning needs to identify meetings by their UID. (It was a light-bulb moment when I realised this was how Lightning looked up an invitation in the Inbox and linked it to a event in the calendar.) Now I've historically stored the server-side item id (which is a completely different id) in the metadata so that if the server tells me that an event was deleted I can find the corresponding UID by looking through the calendar's metadata, and also so that if the user changes the event then I can find it on the server from the metadata (obviously the server's id is not a property of the event). I assume you're going to tell me that as an extension I should be using extension storage instead for this, which somewhat defeats the object of supporting metadata. But if I can keep on using metadata, then I need to be able to access the metadata before an item is deleted, and I also need a way to get all of the metadata, so that I can look up the server-side id and find the UID from it. My idea was to return it when doing a get on the cached calendar. (I also still wonder what to do with the variables the server gives me to help my stay in sync. Historically I've saved those as calendar properties.)

Speaking of UID, I don't know whether it would be less confusing to use uid rather than id as the name of the identifier of an event?

It would be nice if it was possible to synchronise just one calendar. Currently if your extension isn't ready then it misses out for half an hour, or otherwise it forces everything to synchronise.

It's annoying that the API for creating and updating events is subtly different, in that creating events requires you to have the id and type as members of the properties, while updating passes the id as a separate parameter and not in the properties. My preference would be to have createEvent, createTask and update methods, all having parameters calendar, id, properties.

The dates in items are currently being provided in iCal format. I'm in two minds about this, as I'm used to using ISO date format in JSON, but may also be some advantages to iCal format.

Obviously only a few event and task fields are currently supported, but there are lots of considerations for the future, such as whether the user has requested invitations, and whether the extension supports them or should let Lightning handle them.

Finally (well, so far at least) I'd like to note that I found the cache API awkward. I think it would be more obvious to have the functions which operate on the cache (particularly clear, but also the functions for item modification) in the calendar.provider namespace rather than faking it using a cacheId.

[NeilRashbrook]

Your existing convertAlarm function, which I hadn't realised was there before (because it's currently only used for firing alarms), only provides the alarm offset as an iCal string, and I don't have any way of converting it to (say) seconds.

[NeilRashbrook]

I've just realised that you're not actually supporting scheduling meetings yet, which is why invitations just show up as events.

Who's going to be responsible for emails? Ideally, I'd like to opt-in to sending emails. I'd prefer to be given the MIME source. While I can generate invitations and cancellations independently I would need to know when to send cancellations as part of the deletion of a meeting. Responding to invitations is also tricky, as Lightning doesn't conveniently provide that information at all.