← Back to team overview

ubuntu-appstore-developers team mailing list archive

Re: Shipping plugins as click packages

 

On 09/22/2013 06:09 PM, Loïc Minier wrote:
> On Wed, Sep 18, 2013, Daniel Holbach wrote:
>>  - this would be plugins or addons which are not part of the
>>    default install
>>  - they probably wouldn't use confinement
>>  - they probably wouldn't need to be listed in the store, but
>>    maybe in a special category, so they could be installed on
>>    demand or automatically(?)
> 
> thanks for starting this; the specific example is GStreamer plugins,
> typically providing extra codecs.  These would be available for all
> Click apps calling into QtMultimedia which uses GStreamer, and to system
> apps such as webbrowser-app, mediascanner etc.
> 
> I was thinking we could achieve this by having some flag in the Click to
> indicate it's a GStreamer codec, then have a hook that would pick up
> such installation to deploy the codec in an end-user or system-wide
> directory.
> 
Don't have to have a special flag; just define a hook for it. Eg:
  "hooks": {
    "some-gstreamer-codec": {
      "codec": "<something>",
    }

/usr/share/click/hooks/codec.hook then looks at "<something>" to figure out what
to do. Maybe this is a list of files to put in place, maybe it is something
else. I suggest talking with the click team

> We would hide these from search results by default, but be able to
> install as needed (similar to what we do with GStreamer elements on the
> desktop).
> 
This is a fine idea, but implementing this requires additional design because
apps shouldn't be allowed to install these codecs themselves without the user
knowing about it. One way to implement this would be to have some underlying
library call out over DBus to a codecs service. Apps with the audio/video
permission are allowed to talk to this service. When contacted, the codec
service prompts for confirmation in some meaningful manner (needs design team
input). The codecs service would likely integrate into tvoss' upcoming
trust-store, but should not cache the result for later (ie, we would always
prompt the user on new codec installs, rather than prompting once and then
saying the app is always allowed to download codecs thereafter).

There might be other ways to do this safely. The first iteration might just be
to have the codecs available in searches in the app store so that users can
install them directly.

> Review scripts would catch this class of Clicks and require them to
> come from com.canonical.xyz or something like that.
> 
Yes. This is a hard requirement since the codecs are not guaranteed to be run
under application confinement and therefore would be allowed to do anything on
the system.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature


References