See also bug 776294.

Bug 772747 is going to introduce new settings "ril.mms.apn", "ril.mms.xxx". We should use these new settings names.

I used to have some experiences on the settings. If no one is looking into this one, I'm glad to take it. Please let me know.

(In reply to Gene Lian [:gene] from comment #2) > I used to have some experiences on the settings. If no one is looking into > this one, I'm glad to take it. Please let me know. Thank you a lot, but please wait until bug 772747 is settled down.

Is this a V1 feature or basecamp-blocker?

It's not a V1 feature, but since we already have part of MMS function working, and MMS is really an important feature, supporting this earlier will benefit on MMS development & testing.

Since we're going to support some initiative testings recently, I'll start working on this to hook up the MMS back-end functions to Gaia-end.

Take a look at https://github.com/mozilla-b2g/gaia/pull/6483. That code is part of the operator variant logic.

Hi Vicamo, Could you please return some feedback when you're available? Thanks! The following summarizes what I've done in this patch: 1. I used the following structure to cache the current MMS settings, which will be updated whenever the settings are changed or initialized when the MMS service starts up. MMSProxyInfoSettings: { "mmsc": null, "mmsproxy": null, "mmsport": null }, 2. Another local variable |MMSNetworkConnected| is used to specify whether the MMS network is currently connected. Note that the |MMSProxyInfoSettings| is valid only when the |MMSNetworkConnected| is true. 3. An |MMSProxyInfoSettingsToRead| is used to specify whether the |MMSProxyInfoSettings| is completely read during initialization. 4. I understand there could be an edge case that |MMSProxyInfoSettings| is not completely updated during run-time but I prefer firing another bug to address that since it needs lots of changes in our current settings service mechanism.

Just some fine tunes. Please see the main summary in the comment #9.

Comment on attachment 686036 [details] [diff] [review] WIP Patch V2.1 Review of attachment 686036 [details] [diff] [review]: ----------------------------------------------------------------- It's nice! Let's do it this way and hopefully we can integrate all the mms related setting entries into one someday.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #11) > Comment on attachment 686036 [details] [diff] [review] > WIP Patch V2.1 > > Review of attachment 686036 [details] [diff] [review]: > ----------------------------------------------------------------- > > It's nice! Let's do it this way and hopefully we can integrate all the mms > related setting entries into one someday. Thanks for the review! I'll come back with a formal patch after more testings to make sure everything is feasible. Btw, the Bug 779381 addresses the issue of multiple settings in a single set.

This patch perfectly synchronizes both settings and preferences by taking the settings.js into consideration. Also, the preference fortunately has an observer mechanism to listen to the preference changes, so we can listen to the "nsPref:changed" observer topic to update the cached proxy info at run-time. Could you please take a chance to review this patch? Thanks a lot!

Rename some variable/function names to make them more readable. Please see comment #13 for the main summary. Thanks!

Sorry. Fix a spot.

Damn... wrong patch. Sorry for the noise!

Fix some nits based on the review in person.

Comment on attachment 687014 [details] [diff] [review] Patch V3.4 Review of attachment 687014 [details] [diff] [review]: ----------------------------------------------------------------- Thank you :)

This bug relates to MMS features and needs to be tagged as leo+ so that we can uplift it into the b2g-18 branch.

The entire set of clian's pushes was backed out for multiple reasons. https://tbpl.mozilla.org/?tree=Mozilla-B2g18&rev=a0b06192f882 1.) The tree rules are clear that you are not to land on top of bustage. At the time you pushed, both B2G Mn and B2G xpcshell had bustage from prior commits that hadn't been backed out yet. 2.) The tree rules are also clear that you are to watch your pushes for any bustage and handle them accordingly. mozilla-inbound is the ONLY tree where this rule does not apply. 3.) Even after the earlier bustage was backed out, something in one of your many pushes was causing further B2G Mn failures as shown in the log below. https://tbpl.mozilla.org/php/getParsedLog.php?id=20424173&tree=Mozilla-B2g18 4.) This isn't cause for backout by itself, but it is also strongly preferred to not push each commit individually as our build and testing resources are limited and doing so stretches them even thinner. Please limit your number of pushes as much as possible unless you have good reason for keeping them separate.