| Summary: | Overrides for vendor extensions | ||
|---|---|---|---|
| Product: | accountsservice | Reporter: | Iain Lane <iain> |
| Component: | general | Assignee: | Iain Lane <iain> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | desrt, marius.vollmer, rstrode, stefw |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Support overrides for vendor extensions
Quieten warnings, otherwise we get warnings for vendor overrides |
||
|
Description
Iain Lane
2013-11-08 16:12:18 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? (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. Created attachment 89417 [details] [review] Support overrides for vendor extensions Not massively sure about the nested hash tables. Created attachment 89418 [details]
Quieten warnings, otherwise we get warnings for vendor overrides
-- 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.