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 <[email protected]> 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
