Features/Thunderbird/BigFiles: Difference between revisions

Jump to navigation Jump to search

Features/Thunderbird/BigFiles (view source)

Revision as of 09:56, 28 September 2011

295 bytes added ,  28 September 2011
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
<div style="margin: 5px 0px 5px 0px; width: 300px; border: 1px solid green; padding: 5px; background-color: #CFC; text-align: center;">[[Features/Create new | Contribute to this feature. ]]</div>
{{FeatureStatus
{{FeatureStatus
|Feature name=Big Files
|Feature name=Big Files
Line 4: Line 5:
|Feature version=Thunderbird  11 or 12
|Feature version=Thunderbird  11 or 12
|Feature health=OK
|Feature health=OK
}}
}} {{FeatureTeam
{{FeatureTeam
|Feature product manager=Jb Piacentino
|Feature product manager=Jb Piacentino
|Feature feature manager=Jb Piacentino
|Feature feature manager=Jb Piacentino
}}
}} {{FeaturePageBody
{{FeaturePageBody
|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.  
|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.  


Line 57: Line 56:
# Others: FTP, network drives
# Others: FTP, network drives
|Feature 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.
|Feature 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.
}}
}} {{FeatureInfo
{{FeatureInfo
|Feature priority=Unprioritized
|Feature priority=Unprioritized
|Feature roadmap=Thunderbird
|Feature roadmap=Thunderbird
|Feature list=Thunderbird
|Feature list=Thunderbird
}}
}} {{FeatureTeamStatus}}  
{{FeatureTeamStatus}}
== Questions not answered ==


Marketing:
== Questions not answered  ==
* How to position this feature vs attachment. This is NOT a replacement to file attachment. (see 'Non goals' section below)
* 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:
Marketing:  
* 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.


Implementation:
*How to position this feature vs attachment. This is NOT a replacement to file attachment. (see 'Non goals' section below)  
* 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 ?
*Not all online storage services categories can possibly be addressed in v1. What guiding principles to apply to make a choice&nbsp;? (do we know the user segment most interested in this&nbsp;?)
* In the same idea, what behavior to expect if the email is forwarded to someone not on the original distribution list ?
*Are there differences in different countries&nbsp;? Some consumer storage providers more popular in some countries&nbsp;?
* What technology for provider API implementation ?


* Can this be done through a web app exposing web intents ? Can the web app be local ?
Use cases:
* 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)
*How to deal with offline mode&nbsp;?
*Are there cases where TB should or could delete a file&nbsp;?
*Should the online file make reference to the email that created it&nbsp;?
*Some online storage services have file expiration dates (on free accounts). Is it acceptable&nbsp;? Can the recipients understand there is a limited lifetime to the link&nbsp;?
*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&nbsp;? Is it mandatory (can we use web APIs for TB and let users choose to install the client if they want to&nbsp;?)
*Does the local client helps offline use (sync happens when going online, in the background)&nbsp;?
*Recipients must not have to register to the online service provider to have access to the online file.


* 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:
Implementation:  


X-Mozilla-External-Attachment-URL: file:///C:/Users/David%20Bienvenu/Documents/75960.pdf
*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&nbsp;?
*In the same idea, what behavior to expect if the email is forwarded to someone not on the original distribution list&nbsp;?
*What technology for provider API implementation&nbsp;?
 
*Can this be done through a web app exposing web intents&nbsp;? Can the web app be local&nbsp;?
*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 &amp; 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:
<pre>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"
X-Mozilla-Altered: AttachmentDetached; date="Tue Sep 27 09:20:29 2011"
 
</pre>
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.
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.
Jbpiacentino
139

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/352305"

Navigation menu