On Fri, Jun 27, 2014 at 3:05 AM, William Reade <william.re...@canonical.com> wrote: > I think one of the biggest problems is the naming: state/api is a hackish > and minimal api client implementation, while state/apiserver is where the > actual api is defined... except the params package, which for some reason > lives under state/api. > > I think the most important actions are: > > * move state/api/params under state/apiserver > * move state/apiserver to the top level, and make sure it's clearly > documented > > Then I'd be keen to separate the internal api client code from the external > one; and at that point I'd be happy to move the external api client code > into its own repo. There's no disadvantage to having that code external, > because we can't afford to break our external api clients regardless; for > the internal ones we have more power and control, because we're the only > ones who have to deal with the impact of change. > > (This would then involve separating the protocol-level code out somewhere > *else*, so that we could reuse it both internally and externally; and we'd > probably want both the server and client protocol parts together; but I > think that the point where we can reasonably move a package outside the main > repo is some way away regardless, so I'm not keen to focus on it at the > moment.)
This all sounds great. It's basically what I was trying to suggest. :) I just don't have as clear a picture of the distinction between internal/external client, which is where I went awry. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
