-----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----- -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
