[Devel] Preferences and Persistence design 0.3.0

Philip Withnall philip.withnall at collabora.co.uk
Mon Jan 11 18:09:31 GMT 2016


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>; dev
> 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>;
> > dev
> > 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
> > > 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/20160111/6dbe7e96/attachment.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/20160111/6dbe7e96/attachment.bin>


More information about the Devel mailing list