Re: RFC: Ubuntu Touch, MMS, and Provisioning

[Slava Monich <slava.monich@jolla.com>]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

Hi Marcel,
> I am not even sure what’s your goal here? Are just trying to plain copy the horrible crap that Android puts in front of their users? You do realize that their list of APNs just purely exists since they never figured out on how to do the automatic provisioning properly and user friendly.
>
> I have to second Denis here that time is better spent in creating a proper provision database instead of just copying what AOSP provides. For example many operators are using SPN or IMSI prefixes to clearly identify their MNVO. We made the provisioning a plugin design for exactly that reason so that every product can provide its own database.
>
> You might also think this through once more. What does default actually mean. Can every context have a default tag? Which one do you pick then? Who is making this policy and who is ensuring what is active at what time. oFono is happily supporting multiple Internet contexts and have them all active. Our own modem hardware supports many contexts. We have run this with 4 Internet contexts at the same time (different and same ones).
>
> And I have to note that oFono never establishes contexts by itself. The only thing that oFono does is attach to the GPRS (packet switched) part of network. The APN establishment is a policy enforced by ConnMan for Internet contexts and mmsd for MMS contexts.
>
> The simplest approach we found with our devices is to only provide one Internet context from the user interface. If it is wrong for whatever reason or provisioning can not identify it, then the user gets asked once. If user wants to change it they can go through the APN setup process once more. Worked smoothly for us and is super user friendly.

I simply gave you a couple of more or less real life examples as why 
people may want to associate additional information with connection 
contexts and keep it persistent across SIM swaps. It doesn't means that 
I'm actually doing exactly what I have described. And in any case it's 
not my job as a middleware developer to design the UI. But in the end 
when it's decided which settings should be per-SIM and which are global, 
I see ofono which I'm already using and which implements persistent 
per-SIM storage, property change notifications and other niceties and 
wish I could just add a few little properties there.

I thought I suggested a simple, flexible and perfectly backward 
compatible solution which would allow to avoid both a) unnecessary 
forking of ofono and b) public arguments about "horrible Android-like 
crap", "you are doing it all wrong", "you don't really need that" and 
such. And yet let people do what they think is right for their own 
project. Doesn't that sound good?

Regards,
-Slava