ubuntu-appstore-developers team mailing list archive

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

On Wed, Mar 5, 2014 at 3:45 PM, James Tait <james.tait@xxxxxxxxxxxxx> wrote:
> -----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.

Hi James, thanks for working on this.

I think it would be great to have some UX designs for "browsing the
store by category (or department)", in order to comment on how these
APIs would fit.
I'm asking around and will comment after I've seen some designs.

cheers,
-- 
alecu