880548 - Generalize activity content type handling

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[[:fabrice] Fabrice Desré]

Attachment: patch

Currently we only map application/pdf to a trigger a "view" activity. This patch adds support for all the activities declared as "view" with a valid mime type.

That will let 3rd party apps handle existing or new mime types without platform changes.

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

The code looks fine to me (and I would r+ it if I'm wrong) but I have heard that we possibly want to implement a kind of download manager. Not that I like a central location to handle those but that would change a little bit the game such that applications will not have to implement their own download code (which is a bit tricky with the current model when it comes about authentication).

Let me CC Casey and see if he has a word on it.

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 759536 [details] [diff] [review]
patch

Fabrice, I'm removing r? until the path is clearer to me. Feel free to ask again when the road is clear (maybe you have more informations than me about the subject :))

Comment 3

[[:fabrice] Fabrice Desré]

ok... but this patch only let 3rd parties do what only the pdf app does today.

We still need something for content types that are not handled by any app, and this is where some kind of download manager is useful imho.

Comment 4

[[:fabrice] Fabrice Desré]

Casey, can you provide feedback there?

Comment 5

[Aditya Bhatt [:adityab]]

Vivien, I think this is a pretty useful patch. I'm writing a many-formats document viewer app, and this approach seems, at the moment, the only way forward for my app to be launched.

Would a download manager not be possible in the very near future? In that case, maybe there's no harm in landing this patch since it doesn't seem to entail any UX changes.

Just my 2 cents. :)

Comment 6

[Stephany Wilkes]

Casey has had some PTO/OOO recently but will get to this when he can. :)

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Aditya Bhatt [:adityab] from comment #5)
> Vivien, I think this is a pretty useful patch. I'm writing a many-formats
> document viewer app, and this approach seems, at the moment, the only way
> forward for my app to be launched.

I also found that very useful.

> 
> Would a download manager not be possible in the very near future? In that
> case, maybe there's no harm in landing this patch since it doesn't seem to
> entail any UX changes.
> 


The current approach has some hard limitations with authentication and furthermore each app would have to implement their own cross-domain download mechanism. This would also force all of those readers to be privileged to access systemXHR.

For those reasons I would like to have a bigger picture and see how we can solve those issues.

> Just my 2 cents. :)

Just my 2 cents too ;)

Comment 8

[[:fabrice] Fabrice Desré]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #7)

> 
> The current approach has some hard limitations with authentication and
> furthermore each app would have to implement their own cross-domain download
> mechanism. This would also force all of those readers to be privileged to
> access systemXHR.
>
>
> For those reasons I would like to have a bigger picture and see how we can
> solve those issues.

I wonder if we could leverage the datastore api to store downloaded content there, and let apps retrieve content from the datastore. I need to dig a bit into that to check if we have blob support in the datastore.

Comment 9

[:Harald Kirschner :digitarald]

More use cases: We have at least one partner who wants to implement ODF/document viewers and depends on this. They are eager to work closely with us.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Harald Kirschner :digitarald from comment #9)
> More use cases: We have at least one partner who wants to implement
> ODF/document viewers and depends on this. They are eager to work closely
> with us.

I still don't think asking each apps to downloads stuffs is the right way to do it since this will not work for authentication case and they will have to implement pause/resume for slow networks, etc...

But in the meantime I changed my mind and we can still delegate that to apps until we implement this download manager that may have a UI/UX at some point in the future..

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 759536 [details] [diff] [review]
patch

Let's apps have fun.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

GetContentTypes is pretty handy; do we intend to surface that via WebAPI so the e-mail app can know what mime-types are supported?

Comment 13

[[:fabrice] Fabrice Desré]

(In reply to Andrew Sutherland (:asuth) from comment #12)
> GetContentTypes is pretty handy; do we intend to surface that via WebAPI so
> the e-mail app can know what mime-types are supported?

I don't know of any concrete plans to do that but I understand the use case. MMS could probably use that too. The simple thing could be someting like navigator.supportedMimeTypes returning an array of strings, but I have no idea if that's ok to do that.

Comment 14

[[:fabrice] Fabrice Desré]

https://bugzilla.mozilla.org/show_bug.cgi?id=880548

Comment 15

[[:fabrice] Fabrice Desré]

hrm, https://hg.mozilla.org/integration/b2g-inbound/rev/f576e6d6dca5

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f576e6d6dca5