← Back to team overview

ubuntu-appstore-developers team mailing list archive

Re: Supporting newer frameworks

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. :)

JT
- -- 
James Tait, BSc. | https://launchpad.net/~jamestait/
Software Engineer, Canonical Online Services, Web and Ops Team
Ubuntu - Linux for human beings | www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJVK2oACgkQyDo4xMNTLiZubwCgjy5HVwV+em/pzkqs05REuP5j
xiEAoJOmyY9M0U6m+KR6mcIOFEAYCq5t
=B3oy
-----END PGP SIGNATURE-----


Follow ups

References