Splitting out state/api into its own repo

[Eric Snow]

On Fri, Jun 27, 2014 at 3:05 AM, William Reade
<william.reade at 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