Privacy/Reviews/ThunderbirdBigFiles: Difference between revisions

Privacy/Reviews/ThunderbirdBigFiles (view source)

Revision as of 15:46, 29 March 2012

661 bytes added , 29 March 2012

→‎Architecture

Bienvenu

589

edits

@@ Line 30: / Line 30: @@
 In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.
-'''The main objective of this feature/product is:''' (describe the goals of the feature/product here)
+'''The main objective of this feature/product is:
+* store large file attachments in online storage
+* providers are XPCOM components
+* cooperating with service providers on both a technical and business side
+* can be pulblic services or private (ie. local ftp)
+* Files are uploaded when you attach them, possibly also from the attachment box afterwards.
+* "provision" UI
+* "logging in" UI
+* "attachment" UI
+* receiving a mail would have a link with some annotations created by Thunderbird.
 '''Design Documents''':
-Link to any design or architectural documents here.
+https://wiki.mozilla.org/Features/Thunderbird/BigFiles
 == Components  ==
-Describe any major components in the system and how they interact.  Also include any third-party APIs (those Mozilla does not control) and what type of data is sent or received via those APIs.
+Each big file provider is a component. The mail compose code uses the nsIMsgCloudFileProvider.idl interface to talk to the big file provider. The big file providers then use their own API to talk to their servers. This communication is specific to each provider. The general flow is authentication of the user, followed by uploading of file contents, and retrieval of a link to the shared file. This link is then included in the e-mail sent to the mail recipients.
 === Component X  ===
@@ Line 75: / Line 84: @@
 |
 |}
 = User Data Risk Minimization =