On 08/04/2013 06:32 PM, Brian Smith wrote:
4. I think we should be working towards a goal of making DeviceStorage
permission from the email app, by improving the capabilities of the
alternatives that would make the use of DeviceStorage unnecessary.

(I am assuming s/making DeviceStorage permission/removing the DeviceStorage permission/)

Using
gmail.com in the browser should be as convenient, with respect to how an
email app accesses the file system, as our built-in email app. So, I think
it would be best if we avoided optimizing for the case where the email app
has DeviceStorage, even if we have to continue using DeviceStorage until an
alternative DeviceStorage-less implementation can be done. (Also, I am
curious what exactly we'd need to improve in the platform to make it so the
built-in email app doesn't need DeviceStorage.)

There is a UX proposal/spec along these lines. If you check out "email-attachments.pdf" from https://mozilla.app.box.com/applications/1/864506434 (or manually traversing "Email", "Interaction" from https://mozilla.app.box.com/applications/ when that link inevitably breaks), you can take a look starting from page 23, "Viewing and saving attachments".

The main idea is that the e-mail app does not directly save attachments to DeviceStorage like we do now. Instead, we'd host the Blob in IndexedDB. When the user clicks on the attachment to view it, we use a web activity to open the viewer, and from that viewer the user can choose to "save" the attachment, presumably to DeviceStorage, but it really would be up to the app implementing the view activity.

I personally like this idea a lot just because I always thought it was dumb on my Android device when I would receive a voicemail message via e-mail, have to download the file to listen to it, and then the voicemail is forever in my music library until I delete it.

Andrew
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to