[Epic] Attachment thumbnails

[chibenwa]

What ?

As a user, I want to preview my attachments from within the application, before even starting to download it.

Example of thumbnails on GMail:

Acceptance criteria

• Reasonable runtime costs: thumbnails should not account for more of 10% of the runtime costs
• Reasonable storage costs: thumbnails should not account for more of 10% of the storage costs
• Displaying a thumbnail should take no more than 500ms on average and no more than 2s in p99.

How?

Design a JMAP extension, that, given an attachment id, would return the blob Ids of its thumbnails.

The thumbnail computation could be done through a mailbox listener calling something like https://github.com/apache/sling-org-apache-sling-thumbnails to extract the thumbnails and store them.

Or more: https://github.com/linagora/linshare-thumbnail-server#readme

Special considerations that needs to be taken into account: RFC-8621 implementation is currently not backed by attachments but directly by the mime body parts. Should we do something smarter? Or thumbnails could be computed from the mime parts directly?

Alternatives:

• Computing thumbnails on the fly and caching them in Redis?

Dod

• Given an email with an attachment added, it's thumbnail is added and exposed
• When the attachment is deleted, its thumbnail is deleted to
• Given a delegation to somebody else mailbox, I can access the thumbnail
• Without the rights, I can't access the thumbnail
• Benchmarks off the thumbnail generation process, of the thumbnail access process.

Related links

• Flutter story Attachments thumbnails tmail-flutter#1198

[chibenwa]

• Experiment with LinShare thumbnail server (curl exemple)

https://github.com/linagora/linshare-thumbnail-server/blob/master/README.md

https://github.com/linagora/linshare-docker/blob/master/docker-compose.yml#L87

https://github.com/linagora/linshare-thumbnail-engine

https://github.com/linagora/linshare-thumbnail-server/blob/master/src/main/java/org/linagora/linshare/thumbnail/server/ThumbnailResource.java

Test: https://github.com/linagora/linshare-thumbnail-server/blob/55061442ab37aeaddc233471a35e3142e24b0c89/src/test/java/linshare/linthumbnail/dropwizard/DropwizardRestTest.java#L86

• Design a JMAP API for getting thumbnails

-> capability for it
-> Proposal : GET download/{accountId}/thumbnail/{blobId}?size=small|medium|large

404 if no humbnail available

• Ticket split for the implementation
  • 1. Mailbox listener computing the preview for a given mail (attachments + mime parts) #597 (QUAN)
  • dedicated bucket? => yes + configurable level of performance of the blob store.
  • Storage in S3 thumbnail-bucket/{jmap-blob-id}-small thumbnail-bucket/{jmap-blob-id}-medium thumbnail-bucket/{jmap-blob-id}-large
  • 2. Storage interface for thumbnail #601 (QUAN)
  • 3. JMAP spec (Rene) JMAP spec about attachment thumbnails #593
  • 4. JMAP implemantion (include capability) (Rene) Implement JMAP api route for downloading thumbnails #594
  • 5. HTTP client from linthumbnail (Tung) HTTP client from linthumbnail #596
  • 6. Integrate in tmail docker-compose (Tung) Integrate thumbnail in tmail docker-compose #599
  • 7. Thumbnail feature SHOULD be optional (module chooser) + configuration of the thumbnail URL (Tung) Thumbnail feature SHOULD be optional (module chooser) + configuration of the thumbnail URL #598
  • 8. deployments: preprod (Rene) https://github.com/linagora/james-project-private/issues/601
  • 9. https://github.com/linagora/james-project-private/issues/602 (QUAN)
  • 10. ADR (Tung) Write ADR for thumbnail feature #600
  • 11. Customize linthumbnail server - Support get only one ThumbnailKind in generateThumbnail resource (Tung) Support get only one ThumbnailKind in generateThumbnail resource linshare-thumbnail-server#8

[chibenwa]

https://ci.linagora.com/linagora/lgs/linshare/saas/linshare-thumbnail-server-dockerfile

[Arsnael]

Btw despite the fact it's company soft, should we be worried that it seems it has not really been maintained for easily 2 years, when you look at the dates of last commits?

[chibenwa]

IMO no need to worry as the last contributor is still employed here but good question ;-)