ubuntu-phone team mailing list archive

[James Tait <james.tait@xxxxxxxxxxxxx>]

-----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-----