[Devel] Preferences and Persistence design 0.3.0

[Philip Withnall]

Hi Andre,

That seems like a workable design to me. I will update the design
document to incorporate it and will try to send out a new draft by the
end of the week, although I am prioritising the Sensors and Actuators
design over Preferences and Persistence at the moment.

Philip

On Tue, 2016-01-12 at 12:05 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
> ok lets focus on the last topic ("seamless integration" of common and
> specific entities into one UI).
> 
> First of all lets keep both possibilities:
> a) UI is entirely provided by oem-settings
> b) UI is entirely provided by the application developer
> lets recommend / enforce to use a), lets see b) as last way with
> maximum
> flexibility.
> 
> now lets look to push the limits for a). It's not black or white,
> let's can
> extend its applicability.  
> 
> I am with you, we should prevent the mentioned approach, based on a
> "client-server protocol for embedding the UI"
> "Application developers would have to cooperate in
> implementing it, as the application-provided settings program would
> have to be a client in a client–server protocol for embedding the UI"
> 
> Lets go for a pretty easy approach, there is an entry listed in the
> oem-settings on an app, but the "value" of this entry gets modified
> by an
> executable. This executable gets launched rendered and it provides a
> return
> code. That’s all. Again see this like a "Wizard", e.g. to configure
> email
> accounts. The Wizard is a standalone executable, provided by the app.
> 
> 
> May be to make it more clear let me describe a potential look&feel
> for
> better understanding. Lets assume all apps are listed in one system
> settings
> application with their name and icon - similar like in iOS. 
>  
> 
> 
> Once you choose an App, the releated UI slides in, showing again a
> list of
> entries reflecting the configurable items. 
> 
>  
> 
> Configurations may have further sub chapters, which again slides in
> and
> shows a collection of configurable entities in its own list-view
> (like a
> standard list of list approach). It optionally shows an own / current
> value
> at the calling scree entry (see the first entry in above view for
> "search
> engine" which shows the current one "DuckDuckGo" but also indicates
> that
> there is a submenu available which helps to change it)
> 
> Once you have a complex app-specific thing, lets put it into one
> entry,
> lets (optional) show the last value and lets run it as a standalone
> wizard
> with its own set of UIs (based on ApertisSettingsList). On other
> entry can
> then link to another executable.
> The result is similar like the first seen at the entry for "search
> engine",
> the only difference is that an own executable gets launched to guide
> the
> user. And lets keep the capability to define one return value
> optionally. 
> 
> e.g. like this:
> 
>  
> 
> So finally, we do have a split in one responsibility per "subview"
> (and its
> successors) , it is not "mixed" in a way that _one_ view gets
> composed by
> several clients. In addition, this capability can also be used by an
> OEM-settings Apps (completely realized for/by the OEM) for very
> complex
> interactions not fitting in the prepared ApertisSettingsList scope). 
> 
> Hope you get what I mean. 
> 
> With that we have a good coverage 
> - the majority of cases we cover with approach a) [UI is entirely
> provided
> by oem-settings]
> - for special cases we can add sub views in own executables (wizards)
> like
> explained above [see above]
> - for very rare case, we enable flexibility to implement the complete
> UI
> entirely by the application developer. 
> 
> To be honest, there needs to be a very good reason to go for the last
> option, especially in our business environment where the Apps are
> created
> driven by a business-to-business relationship of the OEM with the
> service
> provider, and it is the OEM who like to keep the control of that
> portion
> outside of the scope of the App (caused by the ui-customization
> interest
> explained before). So typically, as part of the business contract the
> app-developer will be driven to prevent using option 3. So we are
> less App
> developer / capability driven than business requirement driven.
> Nevertheless, let's keep the last option as an exception of the rule
> of
> thumb and with that for flexibility.
> 
> Rgds
> Andre
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
> Gesendet: Montag, 11. Januar 2016 19:10
> An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> devel at lists.apertis.org
> Betreff: Re: AW: AW: AW: [Devel] Preferences and Persistence design
> 0.3.0
> 
> Hi Andre,
> 
> On Mon, 2016-01-11 at 15:20 +0000, Barkowski Andre (CM-CI1/PRM1)
> wrote:
> > it sounds to me that your proposal is fitting to the
> > "responsibility"
> > split (OEM vs App developer), so from that perspective my answer to
> > your question "Does that fit better with what you have in mind?"
> > would be yes. But let me reflect from other perspectives, the
> > packaging & deployment & control & seamless integration 
> 
> OK.
> 
> > I prefer, that the "code" implementing the OEM-settings is deployed
> > with the OS (essential software) outside of the App-package. With
> > that, all code included in the App-package belongs to and gets
> > provided by the App-Developer. Customization within Apps gets
> > realized based on using prepared widgets / css scheming / etc, all
> > in
> > scope of the OS. With that oem-setting app belongs to the OS
> > (essential software), and the App is only providing some data/model
> > to it. But we do not have to adopt _all_ packages to replace the
> > OEM
> > specific settings implementation included in them. 
> > From my point of view it looks like your proposal fulfills that
> > (since there is an application "oem-settings", created and
> > distributed with the essential software), are we on the same page ?
> 
> Yes, precisely.
> 
> > From "control" point of view, I would like to "enforce" the central
> > solution, the using the exception only the complex parts. Launching
> > the "oem-settings" application - instead of using some homegrown
> > App
> > internal solution w/o need - should _not_ be delegated to the App.
> > It
> > should be part of the system software (essential software) to
> > launch
> > it and to cover all common use-cases. 
> > Again, are we on the same page, its _not_ the App who
> > decided/launches the oem-settings on the first hand (but the OEM
> > settings App, who implements the umbrella) ?
> 
> Yes, we agree here too. In my suggestion, the settings UI for each
> application is launched by the system settings application, which is
> written by the OEM. The executable which provides the settings UI for
> an application is specified in the application’s manifest, which is
> also under the control of the OEM.
> 
> > In regard to seamless integration, the "uncommon cases" should be
> > go
> > down to a granularity of a single entry within the settings. So
> > some
> > common, one 1 or more uncommon, again 1 or more common and so
> > forth.
> > I would not like to have a black or white decision, either all are
> > common or the get replaced completely by a proprietary
> > implementation. This is why I referred to Wizards. Its one entry in
> > the settings app, but instead of modifying its value within the App
> > based on an easy standard type, a dedicated executable is used for
> > it. However, finally its seamless included into one view. 
> > Again, I have the feeling your proposal fits to that, but like to
> > be
> > on the same page.
> 
> I don’t think we are on the same page here. In my most recent
> proposal,
> an application’s settings UI is either entirely provided by oem-
> settings, or entirely provided by the application developer. If it’s
> implemented by the application developer, they can use
> ApertisSettingsList (for example) to ensure a look and feel which is
> consistent with oem-settings. However, they could choose to use
> something else.
> 
> The problem with providing a ‘mixed’ solution – where oem-settings
> displays the simple settings for an application, and some code
> provided
> by the application developer displays the one or two more complex
> settings – is that of privilege separation. oem-settings necessarily
> has permissions to write to all GSettings keys for all applications —
> it is part of the trusted computing base (TCB) for settings
> management.
> If code provided by application developers is allowed to run within
> oem-settings, it also gains those privileges, which violates the
> security policy we want for settings.
> 
> Therefore code from the application developer would have to run in a
> separate process and have its UI embedded into oem-settings. I
> provided
> a couple of options for how to implement this in the most recent
> version of the document (‘Alternative model 1’ in §5.1.5 of version
> 0.3.0 of the document). It’s possible, but is a very complex solution
> for a rare situation. Application developers would have to cooperate
> in
> implementing it, as the application-provided settings program would
> have to be a client in a client–server protocol for embedding the UI.
> This means that there would need to be app store validation of how
> they
> implemented the protocol, plus testing.
> 
> What I suggest is to go with the black and white solution – not
> implement embedding – and instead make it easy for application
> developers to use ApertisSettingsList (and other widgets which
> replicate the look and feel of oem-settings) in their application
> settings UIs. Subject these applications to app store validation
> checks
> (which I suspect would end up being no more complex than the
> alternative of validating an application’s settings UI can be
> embedded).
> 
> > If we are on the same page in regard to the 3 scopes mentioned
> > above,
> > I don't have any issue with the proposal. Hope you are also happy
> > with the outcome. 
> 
> I’ll start updating the design document once we’ve discussed the
> topic
> above.
> 
> > And thanks for your clarification that GSettings will not allow a
> > setting to be changed if it is not writable. That’s good to know.
> > Also the recommendation to check is as part of app store
> > validation.
> > I fear we will forget all this valuable hints for store validation,
> > because at least I do not collect this hints in a structured way.
> > Hope you are doing that in some way.
> 
> The design documents which Simon and I have worked on recently all
> have
> any relevant app store validation checks listed in them. We have a
> task
> open for collating these and adding any additional checks we can
> think
> of (for older design documents).
> 
> Philip
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
> > Gesendet: Montag, 11. Januar 2016 15:12
> > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com
> <mailto:Andre.Barkowski at de.bosch.com> >; dev
> > el at lists.apertis.org <mailto:el at lists.apertis.org> 
> > Betreff: Re: AW: AW: [Devel] Preferences and Persistence design
> > 0.3.0
> > 
> > Hi Andre,
> > 
> > On Fri, 2016-01-08 at 16:40 +0000, Barkowski Andre (CM-CI1/PRM1)
> > wrote:
> > > -----Ursprüngliche Nachricht-----
> > > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
> > > Gesendet: Freitag, 8. Januar 2016 11:04
> > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com
> <mailto:Andre.Barkowski at de.bosch.com> >;
> > > dev
> > > el at lists.apertis.org <mailto:el at lists.apertis.org> 
> > > Betreff: Re: AW: [Devel] Preferences and Persistence design 0.3.0
> > > 
> > > The design currently gives a couple of options for how those sub-
> > > pages
> > > are implemented, but the differences are technical rather than
> > > user-
> > > facing. In all cases, the intention is that the preferences
> > > application
> > > lists applications, the user selects one, and all the preferences
> > > for
> > > that application are displayed.
> > > Andre: the difference is responsibility & deployment. The
> > > settings
> > > App belongs
> > > to the system chrome, gets defined by the OEM and we expect to
> > > write
> > > (by us) one
> > > new implementation per product. But we keep the Apps out of that
> > > scope. They
> > > are not ruling how it looks like (by providing the UI
> > > implementation
> > > aka look & feel),
> > > they are only defining the data. In a model/view/control pattern,
> > > their focus is limited
> > > to the model.
> > > However, no general rule w/o exception, we would like to keep the
> > > flexibility for
> > > special topics/data, which may need some more complex interaction
> > > to
> > > gets defined. But this
> > > doesn't change the overall approach, it only extends it. This
> > > would
> > > mean for very special
> > > entities (a very small quantity and with that an exception and
> > > not
> > > the rule of thumb), Apps
> > > can provide a UI which gets used to modify a value (e.g. like a
> > > wizard). For this part
> > > we again think about how to customize it to the maximum degree,
> > > but
> > > we accept limits.
> > 
> > I see. I think we could handle this using much of the same code as
> > suggested in my previous e-mail (i.e. the ApertisSettingsList
> > widget),
> > but have that code written by the OEM as an application which takes
> > the
> > name of a GSettings schema as a parameter, and automatically
> > generates
> > and displays a UI for all the settings in that schema. For clarity,
> > let’s call it oem-settings.
> > 
> > Each application’s manifest could contain a key which gives the
> > name
> > of
> > an executable to run to display that application’s settings. For
> > the
> > common cases, that would be:
> >    oem-settings com.appauthor.MyApp
> > i.e. it would run the OEM’s settings application to generate a
> > settings
> > UI for the application (com.appauthor.MyApp).
> > 
> > For the uncommon cases, where the application needs a particularly
> > complex settings UI, the manifest key would be set to a settings
> > program provided by the application developer. This could use a
> > combination of ApertisSettingsList and custom widgets, as suggested
> > in
> > my previous e-mail, to build whatever UI the developer needs. It
> > could
> > also launch the application itself, with a special argument to show
> > the
> > settings dialogue, if that’s how the developer has implemented
> > their
> > settings.
> > 
> > In these uncommon cases, the OEM will be able to control the
> > appearance
> > of the application’s settings dialogue to a certain extent by
> > setting
> > the CSS of ApertisSettingsList. However, as you say (lower down in
> > your
> > e-mail, I think), the OEM won’t be able to control everything. I
> > don’t
> > think there is a way to reconcile this other than through app store
> > validation of the code for the settings UI. If the application
> > developer is allowed to execute //any// code in order to build the
> > settings UI, they can (if they try hard enough) flaunt the OEM’s
> > desired look and feel.
> > 
> > For all cases, the system settings application would initially
> > present
> > a list of all applications which have this key set in their
> > manifest
> > —
> > I guess as an icon against the application name, as in iOS. When
> > the
> > user selects an application, the settings executable given in the
> > manifest would be executed — whether that be the oem-settings
> > application, or something provided by the application developer.
> > 
> > Does that fit better with what you have in mind?
> > 
> > > Where the design currently differs from this is that it advises
> > > //against// automatically generating the preferences UI from the
> > > GSettings schema file. This is advice borne out of the
> > > experiences
> > > of
> > > various of us, who have seen and worked with auto-generated
> > > preferences
> > > UIs. They are almost universally not a pleasure to use, unless
> > > they
> > > list a very small number of very simple preferences (on the order
> > > of
> > > a
> > > couple of checkboxes, for example). You can think of this as a
> > > model–view–controller split: in all such patterns, it is rarely
> > > possible to satisfactorily generate the view from the model.
> > > Andre: yes, I see, but I don't share this recommendation against
> > > it.
> > > Its not black or white, the majority is very simple and on top
> > > we provide flexibility for the exceptions and last but not least
> > > we
> > > have the
> > > need for OEM customization.
> > 
> > I see.
> > 
> > > Instead, it advises creating preferences UIs using code. This
> > > allows
> > > for ultimate flexibility in how the UI works, which can make for
> > > a
> > > much
> > > more pleasant user experience.
> > > Andre: again, I see but don't share it because it does not fit to
> > > our
> > > business model.
> > > Which user experience is pleasant decides the OEM, even if we
> > > find
> > > it
> > > very disappointing.
> > > With that we are talking about different kind of "flexibility".
> > > Since
> > > the majority of preferences
> > > is quite easy, the "flexibility for Apps" is only important for
> > > some
> > > special entities,
> > > but since we adopt the look&feel of each and every product
> > > accordant
> > > to the OEM interest,
> > > we do need "flexibility for OEM". And therefore we restrict
> > > flexibility for Apps.
> > > However, for parts with very good reasons, we will provide it,
> > > but
> > > not as a rule of thumb.
> > > And implementing it using code is not the issue what I am talking
> > > about, the responsibility is the topic.
> > > The system chrome application providing the UI for the App
> > > settings
> > > (which has been created based on code)
> > > will be done by the product team, not the App Developer. With
> > > that
> > > we
> > > keep the maximum level of flexibility for
> > > the settings app (belonging to the system chrome) in our own
> > > hands
> > > (i.e. the product team, out of the App Developer hands)
> > > And like said a new implementation will be done for each new
> > > product.
> > > Its the same for the App-Launcher, the status bar / Home screen,
> > > etc..
> > > But its not based on code to provide flexibility for the
> > > configuration, its based on code to provide flexibility for
> > > the OEM, even for the standard / easy stuff. The complex, very
> > > App
> > > specific stuff can not realized outside the scope of
> > > the App responsibility, so we keep this in their hands with
> > > limitations in customization
> > > (even though we push also the limits as much as possible to
> > > enable
> > > customization for that part to a maximum degree)
> > > However, the approach which I explain is not going for one way
> > > without enabling the other one.
> > > So we have to enable both, minimize the part which is in the
> > > hands
> > > of
> > > the App Dev and maximize the
> > > part which is out of their scope.
> > 
> > OK. Thank you for the clear explanation.
> > 
> > > > - An OEM can decide to remove configurable parts in his
> > > > product,
> > > > so
> > > > that only a subset gets published to the user for a specific
> > > device. 
> > > This is already handled by the vendor lockdown system supported
> > > by
> > > GSettings. Applications can check whether a preference is locked
> > > down
> > > by calling the g_settings_is_writable() method. I will mention
> > > that
> > > in
> > > the document.
> > > Andre: "can" check is not sufficient. We need to deliver the
> > > product
> > > w/o
> > > contacting the App-developer to adopt this part. Again, it’s a
> > > matter
> > > of
> > > responsibilities. So the code is in responsibility of the product
> > > team to the maximum
> > > degree. For the remaining stuff we try to push the limits as much
> > > as
> > > possible, so "can"
> > > would be ok for that.
> > 
> > I should clarify here: GSettings will not allow a setting to be
> > changed
> > if it is not writable. If a vendor has used the vendor lockdown
> > system
> > to fix the value of a specific key, that key will no longer be
> > writable. An application should use g_settings_is_writable() to
> > check
> > whether to display that key in the UI; but even if it fails to
> > check
> > that, any edits it makes to the key will fail.
> > 
> > Any Apertis-provided widgets like ApertisSettingsList would check
> > g_settings_is_writable(), so this is only relevant to the minority
> > of
> > application developers who are writing their own settings UIs, and
> > it
> > could be something which is checked as part of app store
> > validation.
> > 
> > > > Often there are "configurations" which modifies the App
> > > > behavior
> > > but
> > > > used by the system-integrator at point in time of product
> > > > creation.
> > > > By intention, they are not transported to the Used for
> > > configuration.
> > > > It limits the capability of the User, but also reduces
> > > > complexity.
> > > > Its maybe used for variant handling. However, it is highly OEM
> > > > specific, since another OEM my decide differently which
> > > configuration
> > > > capabilities to provide to the User.
> > > This is already handled by the combination of vendor lockdown and
> > > vendor overrides, as provided by GSettings.
> > > Andre: I am not talking about the GSettings capabilities, I am
> > > talking about
> > > the code responsibility for the presentation, and who will change
> > > what in case
> > > an OEM adoption is running into issues. The Settings App / UI
> > > shall
> > > be in the
> > > responsibility of the product team to the maximum degree and
> > > interact
> > > with the
> > > OEM for adoption, but not with each and every App developer to
> > > check
> > > if its
> > > Code has issues with the new presentation solution.
> > 
> > As above.
> > 
> > > > In addition, there could be a sequence needed to ease the input
> > > > of
> > > > values, e.g. a wizard  (e.g. to configure an email account).
> > > > This
> > > > should be provided by the App-Developer. An isolated executable
> > > > (Agent), using some PopUp-Sequence and finally set the key-
> > > > value
> > > > pairs shown in the settings App. With that, the Wizard gets
> > > > shipped
> > > > with the App, but launched by the Settings Apps. 
> > > The wizard, as you describe it, is effectively what we have in
> > > mind
> > > for
> > > all preferences UIs — you could think of them as similar to one-
> > > page
> > > wizards.
> > > Andre: yes, but only for very special cases, not as the general
> > > approach.
> > 
> > Agreed.
> > 
> > Philip
> > 
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Devel [mailto:devel-bounces at lists.apertis.org] Im Auftrag
> > > > von
> > > > Philip Withnall
> > > > Gesendet: Freitag, 27. November 2015 13:05
> > > > An: devel at lists.apertis.org <mailto:devel at lists.apertis.org> 
> > > > Betreff: [Devel] Preferences and Persistence design 0.3.0
> > > > 
> > > > Hi all,
> > > > 
> > > > Please find attached version 0.3.0 of the Preferences and
> > > Persistence
> > > > design, plus a document showing the changes between version
> > > > 0.2.3
> > > and
> > > > 0.3.0.
> > > > 
> > > > This version includes more background research, some
> > > > alternative
> > > > designs for the system preferences application (§5.1.5) and
> > > > clarifications of recommendations for storing secrets and
> > > passwords.
> > > > 
> > > > Is this one OK to upload to the wiki?
> > > > 
> > > > Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160118/d50a79dc/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5445 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160118/d50a79dc/attachment-0001.bin>