ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/09/2013 05:09 AM, James Tait wrote:
> On 09/10/13 09:26, Daniel Holbach wrote:
>> Hello,
> 
>> On 02.10.2013 17:02, Alejandro J. Cura wrote:
>>> Today sergiusens brought up on irc the problem of filtering in
>>> the current image post-13.10 apps that requiere newer
>>> frameworks.
>>>
>>> For that, dholbach suggested adding the versions supported to
>>> the search query, as is currently supported in the spec[1]. For
>>> instance, in two years we would be using a query like this:
>>>
>>> GET
>>> /api/v1/search?q=framework:ubuntu-sdk-13.10,framework:ubuntu-sdk-14.04,framework:ubuntu-sdk-14.10,framework:ubuntu-sdk-15.04,framework:ubuntu-sdk-15.10,description:awesome
>>>
>>>
> HTTP/1.1
>>>
>>> I was thinking of something like
>>> "max-framework:ubuntu-sdk-13.10". But that makes it harder to
>>> remove support for older versions, so I guess adding all of them
>>> makes sense. Sergio also suggested adding ranges, and that's
>>> something we can do further down the lane, without breaking 
>>> compatibility with the current image.
>>>
>>> So, the plan for 13.10 is just to have the click scope add 
>>> "framework:ubuntu-sdk-13.10" to the current query.
>>>
>>> Please add your comments to this thread if you think we got some
>>> part of it wrong, or are forgetting about something else.
> 
>> Did some conversation about this happen already elsewhere?
> 
> Not to my knowledge.  It's a difficult problem - what we really want
> to do is have the client say "I support these versions of these
> frameworks" and have the server filter out apps that declare a
> dependency on unsupported frameworks.  This conversation gets complex
> very quickly though, so I'll try and demonstrate with an example:
> 
> App A requires ubuntu-sdk-13.10 or higher
> App B requires ubuntu-sdk-14.04 or higher
> App C requires ubuntu-sdk-13.10 and fictional-framework-13.13
> App D requires ubuntu-sdk-14.10 and fictional-framework-13.13
> 
> Client X has ubuntu-sdk-13.10
> Client Y has ubuntu-sdk-14.04
> Client Z has ubuntu-sdk-14.04 and fictional-framework-13.13
> 
> Assuming ubuntu-sdk-14.04 will also support apps with a dependency on
> ubuntu-sdk-13.10, we really want to be able to express:
> 
> For Client X, give me all apps that depend upon ubuntu-sdk-13.10 and
> nothing else.
> For Client Y, give me all apps that depend upon ubuntu-sdk-13.10 and
> nothing else, OR ubuntu-sdk-14.04 and nothing else.
> For Client Z, give me all apps that depend upon ubuntu-sdk-13.10 and
> nothing else, OR ubuntu-sdk-14.04 and nothing else, OR
> ubuntu-sdk-13.10 AND fictional-framework-13.13 and nothing else, OR
> ubuntu-sdk-14.04 AND fictional-framework-13.13 and nothing else.
> 
> And the results should be:
> 
> Client X sees App A.
> Client Y sees App A and App B.
> Client Z sees App C.
> Nothing sees App D - although Client Z supports
> fictional-framework-13.13, it doesn't have the requisite ubuntu-sdk-14.10.
> 
> I think for now, the current approach is fine.  However, going forward
> I think supporting range queries is the way to go.  That will require
> some fairly hefty rework, though, in the schema, in determining a
> suitable way to express the required and supported frameworks, and, of
> course, in implementing both client and server sides of that conversation.
> 
> My gut feel at this point is that max-framework:ubuntu-sdk-13.10
> probably isn't going to cut it.  Maybe we could query something like
> 
>   min-framework:[ubuntu-sdk:13.10],max-framework:[ubuntu-sdk:14.04]
> 
> which would then allow
> 
>   min-framework[ubuntu-sdk:13.10,fictional-framework:13.13]
> 
> but, yeah - it's a difficult problem, and one we need to get right. :)
> 

To add a potential complication to this. AppArmor policy for click is
versioned-- eg, right now it is 1.0. However, we expect to bump the policy after
release-- eg, to move the accounts policy group out of reserved status once Mir
supports out of process user prompts. This means that policy will be at 1.1. I
think it probably makes sense to just increment our policy version when the
framework increments, but it is also conceivable that this wouldn't happen (eg,
the framework updates, but there are no policy updates needed).


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