Open Source Telephony
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox