Splitting out state/api into its own repo

[Gustavo Niemeyer]

Hey Eric,

Some comments below, offering a slightly different perspective to be
used as a data point in your quest.

On Thu, Jun 26, 2014 at 1:41 PM, Eric Snow <eric.snow at canonical.com> wrote:
> In the interest of understanding juju better and of making the API
> more accessible, I took a little time to investigate possible
> improvements.  One of the first ones to come to mind was to split
> `state/api` into its own repo.  That smelled like a heavy lift
> especially considering the many interdependencies between `state/api`
> and juju proper (though apparently `go` mitigates that somewhat).

There are a few different arguments bundled together:

1. state/api is a bad location for the state API endpoints

2. documentation is not great

3. moving code into a separate repository makes its orthogonality more clear

The answer for 2 is easy: let's have better documentation. That's
unrelated to where the code sits.

For 1, in my simplistic view state/api feels like a pretty reasonable
place for an http interface that offers access to the functionality in
state.

For 3, splitting it off not only seems to needlessly increase the
maintenance burden, but also feels incorrect from the orthogonality
standpoint: state/api maps state into a public API, and is a critical
dependency for juju to work at all.


gustavo @ http://niemeyer.net