ubuntu-appstore-developers team mailing list archive

[James Tait <james.tait@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello and welcome to the latest exciting episode!  Here's what's been
going on in the last two weeks:

Schema Changes
==============
More details of the Solr schema continue to emerge:

 * The title, description, package_name, version, click_version,
   click_framework and click_updown_url fields will all be required.
 * The package_name field will also have a unique constraint.
 * The click_framework field will be multi-value, to allow developers
   to declare a requirement for other (as-yet-theoretical) frameworks,
   e.g. 'android-compat-4.2.2'.
 * The url fieldType will switch from tokenised TextField to an
   untokenised StrField.
 * The icon_urls field is the biggest change, from a multi-value url
   field to a multi-value payloads field.  More on that below.

Price, categorisation and hardware requirements currently remain
outstanding.

API Changes
===========
Well, not so much changes as definition.  Up until this point the API
has been a fairly loosely-defined proxy to Solr.  But working on the
schema has highlighted a couple of areas that probably aren't going to
translate well into a nice, usable API - icon_urls is a good example of
this, where we'll get a list of values something like
'16|http://example.com/media/myapp/icons/icon16.png' from Solr.  We
think we can do better than that, so the initial thoughts on the API are
something like this:

 * JSON-based.
 * Solr's UpdateRequestHandler will be access-restricted, so only the
   Software Centre Agent can change Click metadata.
 * /api/v1/search will pass through to Solr's SearchHandler for general
   searching.
 * /api/v1/package will perform more restricted searching against Solr's
   SearchHandler to retrieve metadata about a specific package.
   Requests here will need to be carefully managed to prevent things
   like tricking the user into viewing details of a package other than
   the one they think they're viewing.  Responses will be managed to
   ensure things like only having a single package returned.
 * The proxy will serve as access-control, apply sane defaults and
   massage request and response formats, e.g. turning icon_urls from
   ['16|http://example.com/media/myapp/icons/icon16.png'] into
   {'16': 'http://example.com/media/myapp/icons/icon16.png'}

The skeleton for this service is ready, but currently only serving
pre-packaged stub responses.  We're working to get this deployed ASAP.

Other News
==========
Michael Nelson has been doing some fantastic work on packaging all this
up to be deployable with Juju.

The REST API documentation is on the Ubuntu Wiki [0], and will continue
to be updated as we flesh things out.

That's all for now!

JT

[0] https://wiki.ubuntu.com/AppStore/Decisions/REST_API
- -- 
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.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHBdC0ACgkQyDo4xMNTLibIzgCcDQxNerDi80fyxX5/th5Bm6ct
ZdsAnirkwIRrS8irWwfMNpiM50KfYRq8
=oAEB
-----END PGP SIGNATURE-----