Hi Slava,

 > A couple of examples.
>
> Suppose, we have a UI that allows the user to switch between "Automatic"
> and "Custom" MMS or GPRS settings. One of the ways to implement that
> would be to create a new context marked as "manual" and allow the user
> to edit it. The old context remains but it's marked as "automatic" or
> whatever. Manual context has a precedence over the automatic one.
> Switching back to automatic means destroying the "manual" context or
> marking it as "disabled". All that stuff gets saved to the ofono
> SIM-specific gprs file so that these context properties don't get lost
> after swapping SIMs.

That sounds awful from a user perspective.  I don't see why you need to 
store these attributes inside oFono.  Just let the user edit the 
existing context and re-run your provisioning application when the user 
makes the decision to switch back to 'automatic'.  Or better yet, get a 
decent provisioning database so that the user isn't asked for this at all.

>
> Suppose, we have a different connection management system, which shows
> the entire list of available access points to the user and allows to
> choose which one to use. The selected context needs to be marked as
> "default" or something. Again, this context property needs to survive
> SIM swap. With a custom context property that's pretty easy to do.

Feel free to suggest something, maybe a Priority attribute.  But then 
again, a better provisioning database or a dedicated provisioning UI 
would be way nicer from a user perspective.

>
> Every project may have requirements that are more or less unique, often
> influenced by the UI design. There's no need to push support for unique
> project specific requirements into the common code, there's nothing here
> to argue about. It's a matter of whether you want to make ofono a bit
> more usable as is or you are fine with it being cloned and heavily
> modified for each particular project.
>

Knock yourself out then :)

Regards,
-Denis