ubuntu-appstore-developers team mailing list archive
-
ubuntu-appstore-developers team
-
Mailing list archive
-
Message #00778
[RFC] Specifying Client Platform Properties to the Click Package Index
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I wanted to share a couple of ideas that I've had floating around in
my brain, relating to the way certain search criteria are passed to
Click Package Index.
- From a technical standpoint, there are some fields that need "special"
handling:
- architecture: defaults to "all", but specifying it is additive, i.e.
it produces an OR query ("armhf" OR "all")
- framework: a potentially lengthy list of *supported* frameworks,
also additive but with some additional logic
These are platform properties - the user isn't going to enter these in
the dash, they're intrinsic to the device and aren't going to change
from one search to the next. They're also not strict requirements -
the intended meaning is "this device supports these features", not
"all of these features must be required by the package". As such, I'd
like to keep them out of the "user query" part of the request.
I've had a couple of thoughts about how we might approach this:
- Pass them as discrete GET parameters. This has the benefit of being
easy to test in a browser, and totally transparent. It's also less
likely to be problematic with caches. On the down side, it will
lead to very large URLs.
- Pass them as request headers. This keeps the URL shorter and more
focused and is better aligned with other non-user-query attributes
such as GeoIP information and language settings, at the expense of
being largely invisible, (more) difficult to test in the browser,
and may break caching.
- Use an HTTP POST for the search. Without wanting to be a purist,
well, yuck. Also likely to be problematic with caches.
Another thing to consider is that I'd like to include a URL in the
department results that will perform a search for packages within a
given department, so a request to
search.apps.ubuntu.com/api/v1/departments/Games
might produce a result like:
{
"name": "Games",
"subdepartments": [
{
"name": "Games/Board Games",
"resource_url": "s.a.u.c/api/v1/departments/Board+Games"
}
],
"search_url": "s.a.u.c/api/v1/search?department:Games"
}
The search_url should be navigable, and return results appropriate to
the device. Requiring GET parameters for the search would mean they'd
need to be added to that URL, and to the departments URL.
I'd appreciate people's thoughts on this.
Cheers,
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
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMXcMsACgkQyDo4xMNTLiagCQCaA9yg6g1D7ztcdD/DXpQTiIsc
kNQAoMj2CnJnIH5q3bHWae88SXknl1WA
=rL/u
-----END PGP SIGNATURE-----
Follow ups
References