Charm store API proposal, new version

[Aaron Bentley]

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

On 14-07-15 06:05 PM, Richard Harding wrote:
> On Tue, 15 Jul 2014, Aaron Bentley wrote:

> What we lack is your specific use cases as no one working on the
> spec is knowledgeable about how you're using the api.

I'm happy to participate in any discussions you may have, especially
about major changes like eliminating bulk access.

>> We need to provide the statistics that show adoption rates to
>> Mark Ramm and Mark Shuttleworth.  We cannot forsee exactly which
>> questions will be asked.  We need to be able to add new
>> statistics without friction, so we need our own copy of this
>> data.

> What specific metadata do you need?

We currently need only publication dates of all revisions, but we
cannot predict what we will need in the future, so we need to be able
to synchronize our own copy of the data (at least the data which is
available through the public API).

An API that only gave us access to publication dates would not be
acceptable.

> Given that data, when you get the latest version of a charm, you'd
> get a list of previously published versions to facilitate the
> upgrade/downgrade UI. It seems this would help you with the publish
> counts?

If the search is only listing previously published versions, without
providing their metadata, that doesn't help.  Given tip, we can
already predict previous versions.  If we know that tip is, e.g.
cs:precise/mysql-5, then we know that the previous versions are
cs:precise/mysql-4, cs:precise/mysql-3, etc.

> Most of the other data around revisions and bugs we'll do our best
> at, but will be sacrificed information so that users can publish a
> charm or bundle from any vcs. What other metadata should be make
> sure is addressed?

It wouldn't surprise me if we'll be asked to generate information
about charm owners and uploaders, but we have not been asked to
generate any statistics about this yet.  With our other stats, there
is particular interest about whether participants are members of
Canonical or external.

>> Search provides results for only the most recent revisions.  It
>> can stand in for step 1 & 2 of our algorithm, but in order to
>> implement 4 and 5 efficiently, we'd need to do multi-id queries.
> 
> With the previous rev metadata we're missing but also required by
> the juju-gui I think we can resolve this with the current api
> implementation. Let me know if there's more we need to address.
> 
> Thanks for reviewing the doc and providing feedback. We're very
> much hoping to build out a strong consistent api we can use for a
> long time going forward.

If you want an API that is somewhat future-proof, then I strongly
suggest supporting bulk operations.  We went down the path of
single-object operations with the Launchpad API and it was a big
mistake.  It's great for simple operations, but for sophisticated
operations it is slooooooow.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxoDlAAoJEK84cMOcf+9hmLIH/0PKoWbqM2pRsy+/SmKxeipD
0krB7Kf0LguODQ3HuBp42fzCcbIGua9H0xHyf+n16bC4xES2BSeSfvPb82KJJnXd
mKewd0QiBEFai3qkrvzDyVeJ/XrzWdPC5vvLsM2Nf2LH4hNywAqhiW86zY38i7Bc
AVvWAx3tV4+VFEJDVTXQfVuLWTIdoCbRpbszJP5LPN7ln5VjEsRMtAH9cAhUGZsx
AHFbi5km9orHpWXeUg632vvvaS/QDaZ3QsyXA6euP6QyRfFT3zFXToJusE6434Jk
NS4aHd8YBa21GDW6gwVmt7ULP+yQdMsCI27GxT/XpjQ1tamHJfgbS0ujOAQ0qys=
=hgLs
-----END PGP SIGNATURE-----