Before landing bug 889737, need "API compatibility", which should support both old and new APIs in order to avoid breaking existing functionality.

I don't think we should do an API compatibility in Gaia for this. What about this plan: 1. Gecko starts supporting USSD in Telephony.dial() and aliases nsIMobileConnectionProvider.sendMMI() to Telephony.dial(). This should not change anything for users. 2. Gaia replaces calls to dial() with sendMMI() and removes code that was there to check if an number was a USSD. 3. Gecko removes the alias. Also, what happens to cancelMMI() ?

Step 1 seems feasible. Gecko could take care of the changes. Then, for cancelMMI, My idea is like: mozTelephony.dial(number).then(callOrMMIRequest => { if (typeof(callOrMMIRequest) === 'TelephonyCall') { // We got a call. } else if (typeof(callOrMMIRequest) === 'MMIRequest') { // It is an MMI number and gecko is currently processing the request. callOrMMIRequest.onsuccess = function(MMIResponse) { Notify the response by 'success' event. }; callOrMMIRequest.cancel(); // We cancel the pending request. } }) Does it cover all the use cases?

(In reply to Szu-Yu Chen [:aknow] from comment #2) > Step 1 seems feasible. Gecko could take care of the changes. > Then, for cancelMMI, My idea is like: > > mozTelephony.dial(number).then(callOrMMIRequest => { > > if (typeof(callOrMMIRequest) === 'TelephonyCall') { > > // We got a call. > > } else if (typeof(callOrMMIRequest) === 'MMIRequest') { > > // It is an MMI number and gecko is currently processing the request. > > callOrMMIRequest.onsuccess = function(MMIResponse) { > Notify the response by 'success' event. > }; > > callOrMMIRequest.cancel(); // We cancel the pending request. > } > }) > > Does it cover all the use cases? In addition to above user-initiated USSD requests, there are also network-initiated USSD requests, notified by unsolicited ussd events. I think we need to attach 'MMIRequest' object to ussdreceieved event as well to cover this case.

In the current Gaia code, we're calling cancelMMI when we init the app (to make sure we're not sending the mmirequest on an existing session) and when the user presses the close button. Maybe we should have a mmirequest.send() to continue sending on an existing session? That way, we do not need to cancel sessions, we just let the sessions expire.

Setting feature-b2g = 2.1 for tracking 2.1 scope. It looks like the discussion is still going on whether gecko can handle the compatibility. We can then RESOLVED WONTFIX if that's firmed.

Needinfo for comment 4 on API design.

(In reply to Anthony Ricaud (:rik) from comment #4) > In the current Gaia code, we're calling cancelMMI when we init the app (to > make sure we're not sending the mmirequest on an existing session) and when > the user presses the close button. > > Maybe we should have a mmirequest.send() to continue sending on an existing > session? Using this design to continue sending on an existing session is truly nice. :) > That way, we do not need to cancel sessions, we just let the > sessions expire.

(In reply to Anthony Ricaud (:rik) from comment #4) > In the current Gaia code, we're calling cancelMMI when we init the app (to > make sure we're not sending the mmirequest on an existing session) and when > the user presses the close button. > > Maybe we should have a mmirequest.send() to continue sending on an existing > session? That way, we do not need to cancel sessions, we just let the > sessions expire. First, MMIRequest might not be an ussd. It could be something like supplemental service. It seems to me that the back and forth communication only occurs in a ussd session. Other requests are just one-shot commands. So mayeb a better way is to provide a ussdSession in 'ussdreceived' event. Gaia then uses ussdSession.send() to continue sending in the same session. If gaia uses telephony.send(USSD_CODE) when there is an existed session, Gecko will always cancel the existed session before it send out the new request. Overall usage case: 1. telephony.send(USSD_CODE): - cancel existed session before sending out the code. 2. ussdSession.send(): - send the code in the same session - |ussdSession| could only get from 'ussdreceived' event.

(In reply to Szu-Yu Chen [:aknow] from comment #8) > First, MMIRequest might not be an ussd. It could be something like > supplemental service. It seems to me that the back and forth communication > only occurs in a ussd session. Other requests are just one-shot commands. So > mayeb a better way is to provide a ussdSession in 'ussdreceived' event. Gaia > then uses ussdSession.send() to continue sending in the same session. > > If gaia uses telephony.send(USSD_CODE) when there is an existed session, > Gecko will always cancel the existed session before it send out the new > request. +1 This is exactly what we're currently doing on the Gaia side except that it's brittle because Gaia has no way to figure out to which session a ussdreceived event belongs too; while we try to keep only one session active at any time we might mistake an unsolicited USSD message for a reply in a session. The design you propose would allow us to distinguish the sessions from unsolicited messages and should make the Gaia code simpler and more robust.

http://i.qkme.me/361gwd.jpg :)

remove feature-b2g per driver's meeting that this is no longer a committed 2.1 scope. Leave this in [priority] list.

Per comment 2, gecko will handle backward compatibility so we don't need this gaia bug. Going to close it. Aknow, please feel free to reopen it or open new bugs for your convenience and according to your plans of resolving bug 889737. Thank you!

Yes, don't hesitate to reopen if handling the backwards compatibility is too hard. Since comment 2, we've changed the API so maybe it's not that easy anymore.