Bug 71393 - Overrides for vendor extensions
Summary: Overrides for vendor extensions
Status: RESOLVED MOVED
Alias: None
Product: accountsservice
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Iain Lane
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-08 16:12 UTC by Iain Lane
Modified: 2018-08-07 09:29 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Support overrides for vendor extensions (8.60 KB, patch)
2013-11-18 17:31 UTC, Iain Lane
Details | Splinter Review
Quieten warnings, otherwise we get warnings for vendor overrides (1.19 KB, text/plain)
2013-11-18 17:31 UTC, Iain Lane
Details

Description Iain Lane 2013-11-08 16:12:18 UTC
Similar in spirit to GSettings overrides, it'd be nice if the new vendor
extensions could be overridden too. For things like OEMs customising
distribution defaults or distros changing upstream defaults.

Working on a patch to implement this. I'll probably copy the GSettings
approach: arbitrary named .override files alongside the extension they are
overriding, with the latest one winning. File format will be key files.

,----
| [interface]
| property=newdefault
`----

Yell if you think this should be different.
Comment 1 Stef Walter 2013-11-11 09:34:11 UTC
Vendor extensions are already overrides, and are intended to be packaged by downstreams. Couldn't those defaults be placed directly in the extensions? 

Do you have a concrete real world use case that would better explain why the additional complexity is necessary?
Comment 2 Iain Lane 2013-11-14 17:49:18 UTC
(In reply to comment #1)
> Vendor extensions are already overrides, and are intended to be packaged by
> downstreams. Couldn't those defaults be placed directly in the extensions? 

Well, they're overrides of a sort. They let application authors (downstreams of accountsservice?) extend AS to store arbitrary data in there, and specify the defaults. In that case they're a bit like GSettings schemas.

> Do you have a concrete real world use case that would better explain why the
> additional complexity is necessary?

So the same reasoning applies IMO. I don't have a concrete concrete use case right now; I'm anticipating requirements for the Ubuntu phone we've been working on for a little while now. Some of the settings are stored in AS. One case in which it works quite well is for user settings which need to be accessed by the greeter & access controlled by PK, etc.

The system (Ubuntu) can set defaults here, but we'd like for our downstreams (customers, possibly, or maybe our remixes within the project) to be able to change our defaults to whatever suits them.

Without a facility like this, the only way would be to overwrite the interface file, which is where the default is defined. That doesn't play very well with system updates or if multiple people want to override values in the same file. Allowing defaults to be overridden externally solves those problems.

I have some patches which seem to work. Will check them over tomorrow and post them up.
Comment 3 Iain Lane 2013-11-18 17:31:05 UTC
Created attachment 89417 [details] [review]
Support overrides for vendor extensions

Not massively sure about the nested hash tables.
Comment 4 Iain Lane 2013-11-18 17:31:33 UTC
Created attachment 89418 [details]
Quieten warnings, otherwise we get warnings for vendor overrides
Comment 5 GitLab Migration User 2018-08-07 09:29:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/2.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.