ubuntu-phone team mailing list archive

[James Tait <james.tait@xxxxxxxxxxxxx>]

-----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.tait@xxxxxxxxxxxxx> 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-----