Shipping plugins as Click packages
Discuss how to deliver plugins over Click packages
Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.
There's a detailed plan for Unity scopes at:
https:/
But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* any other?
These would most likely be system-wide (per device rather than per user)
Security? What kind of confinment?
Appstore integration? How do we search / hide specific Click types? How do we review these?
End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?
===
Notes from vUDS
https:/
Discuss how to deliver plugins over Click packages
Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.
There's a detailed plan for Unity scopes at:
https:/
But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* online-accounts accounts
* Friends plugins
* desktop webapps in Unity7 (this is in another session)
* greeter visualizations (in discussion)
* app themes?
* sound themes? other themes? -- not really plugins
* any other?
These would most likely be system-wide (per device rather than per user)
Security? What kind of confinement?
Appstore integration? How do we search / hide specific Click types? How do we review these?
End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?
Current Click profiles:
* unconfined
* webapps
* regular apps
Upcoming profiles:
* local scopes
* network-using scopes
Unity scopes would be user-level, it would be possible to install for all users or not
For certain use cases, the effect might be system-wide all the time -- always visible to all users
As much as possible, we should design services to be extensible on a per-user basis
TODO: Loic check whether location-service is system-wide or per-user
How do we confine location-service?
- do we need to confine them at all, or do we rely on partner engagement?
- not that many plugins to review
* To implement codecs or location-service, we could offer a search feature to apps, but apps would just point the user to the right package(s) to install from the store
* Might need search API from the store
* For codecs specifically, we need to review the codecs because they are available to all apps
* For codecs, we'd likely start from .deb and wrap them into Clicks
* Security-wise, we should look at each use case independently and decide how we confine things
Adding metadata to packages might need a specific extension to click's PackageKit plugin in order to be able to search for it; "what_provides" should be the interface name
For themes, we probably only need to extend review scripts to check/validate the data, or reconvert the data, but nothing more
Online accounts: confinement not implemented right now, so would have to be manually reviewed, or specific agreement
There's a plan to move online accounts plugins to run in a separate process so we'll be able to confine them individually (and therefore not require manual review or specific agreement)
Blueprint information
- Status:
- Not started
- Approver:
- Steve Langasek
- Priority:
- Undefined
- Drafter:
- Loïc Minier
- Direction:
- Needs approval
- Assignee:
- Loïc Minier
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
