Closed Bug 899442 Opened 7 years ago Closed 7 years ago

[WAP Push] Add permission for receiving WAP Push

Categories

(Firefox OS Graveyard :: RIL, defect)

All
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:koi+, firefox26 fixed)

RESOLVED FIXED
blocking-b2g koi+
Tracking Status
firefox26 --- fixed

People

(Reporter: chucklee, Assigned: chucklee)

References

Details

(Whiteboard: [ETA:8/2], [FT:RIL], [Sprint:2])

Attachments

(1 file, 1 obsolete file)

Although WAP Push is transmitted by SMS, but its mechanism is much different from SMS.
For the implementation of bug 887157 and bug 887156, we should add a permission for receiving WAP Push messages.
blocking-b2g: --- → koi+
Chuck, my understanding is, you're able to finish this one this week. So, I just marked the ETA as 8/2 in the whiteboard now. If it's not the case, please let me know. Thanks.
Whiteboard: [ETA:8/2]
New permission for WAP Push.
For now, WAP Push doesn't have DOM but only a system message, per bug 853782

I think it's better open WAP Push to privileged app, if some devices doesn't have certified app for that.
Attachment #783099 - Flags: review?(mounir)
Comment on attachment 783099 [details] [diff] [review]
0001. Add permission for WAP Push

Review of attachment 783099 [details] [diff] [review]:
-----------------------------------------------------------------

Moving the review to Fabrice.
Attachment #783099 - Flags: review?(mounir) → review?(fabrice)
Attachment #783099 - Flags: review?(fabrice) → review+
Whiteboard: [ETA:8/2] → [ETA:8/2], [FT:RIL], [Sprint:2]
I don't think we should expose this to privileged apps. My understanding is that we're only building this because carriers have existing infrastructure which uses WAP Push and they want to ship support apps which use it.

For 3rd party apps I think we should use the normal Push API since that's an API which can get standardized.

Is there a reason why we need to expose WAP Push to 3rd party apps?
I expose it because I can't find a reason not to.
If I have to give a reason, it's to keep the flexibility for the situation we haven't taken into consideration.

Maybe phone OEM doesn't provide app handling WAP Push format of carrier, Carrier have to support it through its own app, that might happen on developer phones.
Maybe someone studying WAP Push spec just like to see what it actually looks like, that what bothers me when studying WAP Push CP.
The reason not to is that B2G is intending to be a standardized platform. I.e. we want applications written for B2G to work not just on B2G, but also on other platforms, including non-mobile ones.

The push API which is currently looking more likely to get standardized is the one at https://dvcs.w3.org/hg/push/raw-file/tip/index.html

So that is the solution we should encourage 3rd party developers to use.

My understanding for why we are doing WAP Push as a separate API is only because there are carriers that have existing WAP Push infrastructure that they want to leverage. And that supporting those use cases works fine using certified apps. Is that correct?

If we want 3rd party developers to use a standardized Push API, while still taking advantage of the benefits that WAP Push provides, then we can do that by writing a WAP Push backend for the API linked to above. But that's not what's being worked on over in bug 838057 and in this bug, right? Doing that likely wouldn't let carriers leverage existing WAP Push messages, though it would enable leveraging the technical benefits of WAP Push.
To put it another way, the reason not to expose this API to 3rd party developers is that once we expose an API to 3rd party developers, it means that we have to support that API forever. It is extremely hard to phase out an API from the web, even when very few people are using it.

Since we already have a Push solution for the web, that we are planning to support forever, adding another one should only be done if it brings significant benefits.
https://hg.mozilla.org/mozilla-central/rev/cdc667d2e096
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
No longer blocks: koi-ril
Component: DOM: Device Interfaces → RIL
Product: Core → Boot2Gecko
Target Milestone: mozilla26 → ---
You need to log in before you can comment on or make changes to this bug.