Features/Thunderbird/BigFiles
Status
Big Files | |
Stage | Shipped |
Status | In progress |
Release target | Thunderbird 13 |
Health | OK |
Status note | ` |
Team
Product manager | Jb Piacentino |
Directly Responsible Individual | Jb Piacentino |
Lead engineer | David Bienvenu |
Security lead | ` |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | Blake Winton |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
This Thunderbird feature provides a way to use online storage services to store large size email file attachments. With this feature, email file attachments are replaced by urls pointing to an online file storage server, where the files can be found.
This feature is meant to:
- offer a way to easily share very large files through email
- reduce ‘file too big’ bounce email situations
- encourage file sharing over copying
- save recipients inbox space and eliminate file duplication for multiple recipients
- increase attachment sending and receiving speed
A brilliant way of putting it has been done by xkcd
A tight and smooth integration with Thunderbird will be required to facilitate usage and adoption of this alternative way of sending a file via email. See use cases below for examples of UI integration point.
Online storage services can be of different categories:
- cloud file storage services such as DropBox, YouSendIt, Box.net...
- document management platforms such as Google Docs or MS Skydrive,
- enterprise document sharing resources such as MS SharePoint...
- or more traditional network storage resources such as network drives or FTP folders.
2. Users & use cases
When a user attaches a 'Big File'
If the file is above a certain size, warn the user and offer to use online storage instead of attachment. Note: The size could be an arbitrary value, or set by the user, or even retrieved on the fly by analyzing recipients domains (gmail.com for example has a limit of 25MB).
When an email is bounced
If Thunderbird detects that the bounce reason is a 'File Too Big', offer to resend via BigFile.
On-the-fly setup/signup
If the user is about to use BigFiles but has not configured TB for it, allow the setup or signup procedure to happen on the fly, in such a way that the user should not have to bother pre-confguring BigFiles before first using it. A list of pre-configured online storage services should be proposed for setup or signup.
File detach to the cloud
Detaching a file from an email should be possible both on local/network drives and in the cloud. Detaching to the cloud will save local storage space and make the document accessible from the cloud.
Quota management
Detect over quota situations (mostly in the case of consumer online storage services free offers) and guide towards resolution (signup for premium service, file deletions...)
Advanced features
Some cloud storage services offer advanced features. For example, some consumer online storage services offer document tracking (YouSendIt for example). Making this information available through Thunderbird might be interesting for these users.
Faster attachment transmission
- File is uploaded once regardless of how many users are on the 'To/Cc/Bcc' list - Sending the same file through different emails (to different set of recipients) could reuse already uploaded file, saving the upload time. - File upload/download is binary vs. encoded when using email attachment: twice as less data transfered
3. Dependencies
`
4. Requirements
- APIs access to consumer & professional online storage services. Potential supported services:
- File storage services: YouSendIt, Box.net, DropBox, Ubuntu One, Amazon Cloud Drive
- Document management platforms: Google Docs, MS SkyDrive
- Enterprise services: MS Sharepoint
- Others: FTP, network drives
Non-goals
This is not a replacement to file attachment. Care should be taken to make it clear in the UX (for example through a specific UI), whilst facilitating the use of BigFiles when using 'regular' attachments.
We are also not, for this iteration, supporting the creation of multiple accounts with the same service provider. This will be addressed in a later version.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
Privacy review
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
The bug # for this feature is bug 698925
Work is being done on this feature branch.
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | P1 |
Rank | 010 |
Theme / Goal | ` |
Roadmap | Thunderbird |
Secondary roadmap | ` |
Feature list | Thunderbird |
Project | ` |
Engineering team | ` |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | Things to do.
Milestone 1: (Feb 15th - Done Feb 13th.) (Includes Thunderlympics week.)
Milestone 2: (Feb 29th - we're going to be slipping to Friday.)
Post-Landing:
|
Security | sec-review-complete | Notes |
Privacy | ` | Privacy/Reviews/ThunderbirdBigFiles |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |
Questions not answered
Marketing:
- How to position this feature vs attachment. This is NOT a replacement to file attachment. (see 'Non goals' section above)
- Not all online storage services categories can possibly be addressed in v1. What guiding principles to apply to make a choice ? (do we know the user segment most interested in this ?)
- Are there differences in different countries ? Some consumer storage providers more popular in some countries ?
Use cases:
- How to deal with offline mode ?
- Are there cases where TB should or could delete a file ?
- Should the online file make reference to the email that created it ?
- Some online storage services have file expiration dates (on free accounts). Is it acceptable ? Can the recipients understand there is a limited lifetime to the link ?
- Some providers rely on a synchronization model (Dropbox, Ubuntu one...) vs direct file access (FTP, network drive...). and recommend using an installed synchronization application. Is this a problem ? Is it mandatory (can we use web APIs for TB and let users choose to install the client if they want to ?)
- Does the local client helps offline use (sync happens when going online, in the background) ?
- Recipients must not have to register to the online service provider to have access to the online file.
- What happens when Thunderbird retrieves a message which is marked as having a detached file? Should it download it and store it as if it was an original attachment, then present it with the same UI? That might be the most seamless way of making it seem like ordinary file attachment - but are some files too big even for this?
Implementation:
- Senders _should_ be able to ensure that a big file can only be viewed by the recipients of the email (this should be the default setting). Is this true possible for all providers ?
- In the same idea, what behavior to expect if the email is forwarded to someone not on the original distribution list ?
- What technology for provider API implementation ?
- Can this be done through a web app exposing web intents ? Can the web app be local ?
- Each provider must be supported through an installable provider (web app or add-on), some of which are distributed by default with TB
- FTP servers are difficult to set up for average users (at least to ensure security & privacy). Can this be offered to an average consumer (probably one of the the reason why online file storage are popular)
- Note that Thunderbird already supports external file urls for attachments. We use these when we detach an attachment. We put in place holder headers as follows:
X-Mozilla-External-Attachment-URL: file:///C:/Users/David%20Bienvenu/Documents/75960.pdf X-Mozilla-Altered: AttachmentDetached; date="Tue Sep 27 09:20:29 2011"
But the url could be a http or ftp url. So we could offer attachment storage for messages the user has already received, i.e., detach to the cloud.