-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13/03/14 21:09, Natalia wrote:
> Hello all!
>
> I'm writing to sync up about click package searches and
> architecture restrictions.
>
> There are mainly 2 issues:
>
> * the index is returning unexpected results when passing more than
> one arch, so we are gonna change that and return Bad Request if the
> search query has more than one architecture definition
Makes sense.
> * when no arch is given in the search query, only the apps with
> architecture: 'all' are returned. Martin mentioned this is not the
> expected behavior because:
(Inserting missing context)
17:29 < beuno> nessita, right, there is no OR for arches
17:30 < nessita> nor AND?
17:30 < beuno> nessita, or AND
17:30 < beuno> each device is exactly one arch
17:31 < beuno> CPI isn't a generic index of apps
17:31 < beuno> it's for devices to find apps
17:31 < beuno> each device has one arch
> 17:32 < beuno> There may be a use case to not pass in arch, and
> have that return results regardless of arch 17:33 < nessita> beuno,
> right, we already handle that and return all apps with arch set to
> 'all' 17:38 < beuno> nessita, well, "all" is an arch 17:38 < beuno>
> as in, it's arch independant
This part I disagree with.
In the context of the index, the architecture field is a list of
architectures the package will work on; "all" is a symbolic value
meaning "architecture-independent", or "this package will work on all
architectures" - it's not an architecture in itself.
In the context of a user query, the architecture field (soon to be a
request header [0]) is a statement about the device making the request
- - "I'm an armhf device", or "I'm an i386 device"; there's no such
thing as an "all" device, and forcing the device to include "all" as
an architecture and send a header like "X-Ubuntu-Architecture:
all,armhf" just to be able to see the full list of packages available
to it is superfluous.
> 17:39 < beuno> not passing anything would return everything 17:39 <
> nessita> beuno, that is not the current behavior 17:39 < nessita>
> not passing anything returns only the apps with arch 'all' 17:40 <
> beuno> nessita, k, so that's something to talk to jayteeuk about.
> The client may be implemented in a way where that's not easy to
> change 17:40 < beuno> the use case also doesn't matter that much
> 17:40 < beuno> but for browsing the store from a website, for
> example 17:40 < beuno> without being logged in 17:40 < beuno> we
> wouldn't know what arch to filter by, and would want to return
> everything in the store
Well, the background here is that if we don't know your architecture,
we're not going to guess - we'll just return those packages we know
will work, i.e. those without architecture restrictions. Specifying
an architecture in the query is additive - you get to see those
packages without restrictions *plus* those that are specifically
targeted at your architecture.
It's the same approach we take for GeoIP restrictions - if we can't
figure out where you're located, we just return those packages that
have no restrictions. It's just a question of sensible defaults.
There are a couple of other approaches we could take to this:
- we stop automatically returning packages with architecture:all
* Queries that don't specify an architecture will not filter on
architecture, and will get everything.
* Queries that specify "architecture:all" will return just those
packages with architecture:all.
* Queries that specify a recognised architecture will return just
those packages that list that architecture.
* Queries will need to send multiple values in the architecture
header to see the full list of packages available to them, i.e.
we're shifting the burden to the client.
- we only add architecture:all to other architecture queries
* Queries that don't specify an architecture will not filter on
architecture, and will get everything.
* Queries that specify "architecture:all" will return just those
packages with architecture:all.
* Queries that specify a recognised architecture will get those
packages that list that architecture PLUS those packages with
architecture:all.
* Queries will only need to send a single value in the architecture
header to see the full list of packages available to them.
- instead of passing the symbolic value "all" if no architectures are
specified for a package, we allow SCA to pass an empty list. The
index will not store an architecture field for these packages.
* Queries that don't specify an architecture will not filter on
architecture, and will get everything.
* Queries that specify "architecture:all" will return just those
packages with no architecture field (i.e. we special-case this
value for the architecture field, effectively shifting the
symbolic value from the index to the query).
* Queries that specify a recognised architecture will return just
those packages that list that architecture.
* Queries will need to send multiple values in the architecture list
to see the full list of packages available to them (i.e. we're
shifting the burden to the client).
Of these options, I think I prefer the second - package details will
still be explicit (i.e. will still contain "architecture": ["all"]
rather than not returning an architecture and leaving us guessing), we
can still get everything* by not specifying an architecture at all,
but we still get a useful result in a single query if we do specify an
architecture.
> Currently the search results do not return the arch info, so a
> searches with no arch will return information that will require a
> new query per result to be able to show archs to clients, so once
> we change the behavior when no arch is sent in search queries, we
> should be returning the arch in the result.
Would we add this to *all* search results, or just those where no
architecture was specified in the query? It's probably redundant if
the query specified an architecture, but it's inconsistent if we leave
it out.
Cheers,
JT
* Everything, that is, that isn't geographically restricted.
[0]
https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Client_Platform_Properties
- --
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
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMi94IACgkQyDo4xMNTLiZIEACeKemjAnhVPJUhHCDQPEFZ+A9K
/MsAoOw6wdRUjQxjFuBBGG1tRE/0mCwN
=x1fd
-----END PGP SIGNATURE-----
--
Mailing list: https://launchpad.net/~ubuntu-appstore-developers
Post to : ubuntu-appstore-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers
More help : https://help.launchpad.net/ListHelp
