ubuntu-phone team mailing list archive

["Alejandro J. Cura" <alejandro.cura@xxxxxxxxxxxxx>]

On Thu, Mar 6, 2014 at 9:44 AM, Natalia <natalia.bidart@xxxxxxxxxxxxx> wrote:
> On Thu, Mar 6, 2014 at 4:54 AM, Michael Nelson
> <michael.nelson@xxxxxxxxxxxxx> 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?), 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).
>
> +1 too
>
> I need to reuse the architecture and framework filtering for the
> highlights endpoint, and I was also wanting to separated these from
> the "q" param for search.

I like the option with request headers, too.
But, what about older clients that only know about the get params?

I preemptively agree most users are devels using the latest version,
so it is somehow a moot point, but moving forwards I think we can be
more strict on the client side with the User agent string, so we can
later have metrics on the server side on the usage of older features
for these sunsetting scenarios.

cheers,
-- 
alecu