All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: RFC: Ubuntu Touch, MMS, and Provisioning
Date: Wed, 05 Mar 2014 11:52:04 -0600	[thread overview]
Message-ID: <53176444.1040301@gmail.com> (raw)
In-Reply-To: <531760EF.6040203@jolla.com>

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

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


  reply	other threads:[~2014-03-05 17:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05  0:06 RFC: Ubuntu Touch, MMS, and Provisioning Tony Espy
2014-03-05  3:13 ` Denis Kenzior
2014-03-05  9:39   ` Slava Monich
2014-03-05 16:32     ` Denis Kenzior
2014-03-05 17:37       ` Slava Monich
2014-03-05 17:52         ` Denis Kenzior [this message]
2014-03-05 18:29         ` Marcel Holtmann
2014-03-05 21:15           ` Slava Monich
2014-03-05 22:01             ` Denis Kenzior
2014-03-05 23:36               ` Slava Monich
2014-03-06  1:15           ` Tony Espy
2014-03-06  3:04             ` Marcel Holtmann
2014-03-06  0:03   ` Tony Espy
2014-03-06  5:54     ` Denis Kenzior
2014-03-07  4:38       ` Tony Espy
2014-03-07  5:40         ` Denis Kenzior
2014-03-08  0:23           ` Tony Espy
2014-03-08  3:37             ` Denis Kenzior
2014-03-05 17:57 ` Marcel Holtmann
2014-03-05 23:42   ` Tony Espy
2014-03-06  2:41     ` Marcel Holtmann
2014-03-08  0:30       ` Tony Espy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53176444.1040301@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.