-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/03/14 07:54, Michael Nelson wrote: > On Wed, Mar 5, 2014 at 7:45 PM, James Tait > <james.t...@canonical.com> wrote: >> 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. > > +1 for this second option. If the default behaviour when the > headers were missing was to present all results (is that what you > meant by them not being strict requirements?),
Actually, I meant that for the other fields, the user expects to see results where all values are present. For example, a search for keywords:maps,title:google should return Google Maps, but not Bing Maps. On the other hand, a search for architecture:armhf isn't saying "only give me packages for armhf", but "my architecture is armhf - do the hard work for me and discard anything I can't use", and would also return packages with architecture:all; and a search specifying framework:ubuntu-sdk-13.10,framework:ubuntu-sdk-14.04 isn't expecting to find packages that require *both* frameworks, but is instead saying "I support both of these and nothing else - do the hard work for me and discard anything I can't use". They're not strict requirements on the package - all conditions don't have to be met - but a statement about the execution environment. > then testing in the browser won't be any more difficult for some > queries, and curl is easy enough to test with the headers for > anyone (if we have a page with examples for testing). Agreed. And it wouldn't be too difficult to put together a wrapper so people could play with the API. > Caching should not be an issue (assuming we set Vary: headers > correctly in the server response [1]). > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6 In theory, I agree with you - but I've seen caches do some weird things with headers they don't understand! Not strictly our problem, of course, but we still need to do our best to not make life too difficult for those poor souls stuck behind a dodgy proxy. As long as we stick to the specs and are mindful of the potential problems, though, we should be fine. 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/ iEYEARECAAYFAlMYZH8ACgkQyDo4xMNTLiax9gCg3KHPqOr6nx8LrWIYCli7yIz9 /XUAn2ihjbrItuGUmGFIjcmEzDLVGfdp =GdWq -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
