On Tue, 15 Jul 2014, Aaron Bentley wrote: > On 14-07-15 10:17 AM, roger peppe wrote: > > The most significant change is that all endpoints refer just to a > > single charm or bundle, rather than being "bulk" calls as they were > > before. > > That sounds like the opposite of what juju-reports wants. Does it > really mean that we would need to make N requests to retrieve info on > N charms? What was the reason for changing this?
The change is because we went through the known clients and could not come up with use cases where some client had a known list of charm ids they wanted data for, but they knew those ids ahead of time. In the gui, cli, charmtools, etc, we perform queries by a single entity id. The only exception was search, which is a different animal all together and has its own api points for this use. Aaron, I'd like to see if we can get your full use case details and make sure we address them. You had requested an all charms/bundles api call in the last revision of the doc and we're looking at addresssing that through search results. The entity type is a direct filter attribute on a search call. You're also able to describe what metadata about a charm/bundle you'd like to see in a search result. So the thought was that we'd limit the complexity of the api to that known use case. Can you describe your exact use case as a client of the api and we'll look at how the spec/design can be improved to help your use case? -- Rick Harding Juju UI Engineering https://launchpad.net/~rharding @mitechie -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
