Proposed new charm store API

[Richard Harding]

On Wed, 09 Jul 2014, Gustavo Niemeyer wrote:

> On Wed, Jul 9, 2014 at 12:16 PM, roger peppe <rogpeppe at gmail.com> wrote:
> > On 9 July 2014 15:20, Gustavo Niemeyer <gustavo at 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 actually talking about inheriting from two APIs here,
> > charm-store and charm-world, and after some consideration
> > we decided to try to make a single API that takes ideas
> > from both but makes coherent sense in itself.
>
> Are the considerations that justify obsoleting the current charm store
> API written down anywhere?
>
> I'd strongly recommend starting any specification that obsoletes a
> prior implementation or API by explaining why the current one is
> unsuitable. This is even more of the case with an API, as people
> will have to work to fix anything that depends on the previous
> version, so ideally we avoid that altogether, and in the worst case
> we at least provide a great justification for why they'll have to do
> that work.

We can definitely add the discussion points and provide links and details
to the tasks we're hoping to solve with this api update to the spec doc.
This came out of discussions in vegas and planning for jaas so the
reasoning has been gone through but not directly represented in the spec
for the work.

I'm also available if you have any questions around the reasoning and
thoughts behind the proposed spec.

--

Rick Harding

Juju UI Engineering
https://launchpad.net/~rharding
@mitechie