Thanks Aaron, can you add the information and arguments you'd like to make
to the doc. Perhaps add a Missing to the doc and provide the information
you'd like to see returned and such there. Does this need both charms and
bundles? As two calls, in one call, etc.
Rick
On Tue, 08 Jul 2014, Aaron
The idea is that the charm store is growing a lot since the original api
was done. It's gaining a first class entity in bundles, it'll be growing
identity support, search functionality, and other metadata. The api space
is growing and needs to be able to be consistent with other tools as they're
On 9 July 2014 15:20, Gustavo Niemeyer gust...@niemeyer.net wrote:
Is there a reason to reinvent the API from the ground up, instead of
extending what exists today?
We actually started out by thinking that we'd make something
backwardly compatible with the old charm store API, but
we're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I haven't gotten a response on this. juju-reports needs to generate
statistics across all charms, like the published charm revisions
shown here: http://reports.vapour.ws/scorecard
How will it get data on all revisions of all charms?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks. One thing juju-reports needs is a list of all the charms. I
think the API spec doesn't include that.
Aaron
On 14-07-07 05:14 AM, roger peppe wrote:
Francesco Banconi and I have produced a possible specification for
the new charm store
