Thanks to all the responses thus far. While the discussion has been insightful, I'm also hopeful that it will still be fruitful. :)
Understandably the responses have been focused on the main point of my original post, splitting out the API client into its own repo. However, there were a few other points/questions that I think would be worth revisiting (or are effectively still on the table) that were otherwise tucked away here. Following is the original email with the everything but those points snipped away (and edits in square brackets). -eric > For a while I thought `state/api` > held the state API client code, but from what I understand now it > actually contains all the public facing code for the juju state API > (and [consequently?] for juju as a whole?). In some regard I would > expect a public API to be sit in a top-level package (rather than > nested down like it is). > * introduce a juju API client interface type > * is `state/api` just for the state client/RPC, juju state in general, > or juju as a whole? > From what I understand, it is the middle one (though I originally > thought it was the first). > * is there other public juju API other than the state-related API? > * should the `api` [package] contains *all* public-facing juju API > (state-related or not), regardless of whether or not `state/API` > currently does? > * would it be worth restructuring the `api` package to group the > different methods/constants/types by component (e.g. charms/state > archive/tools/services/units/etc.)? > This would particularly impact `api/params`. > * how much should dependencies in juju proper on the `api` package be > dialed back? > I'd think it would be as much as possible. More encapsulation > around the API/RPC part of juju would be good. > * should the underlying state client RPC implementation move over with > `state/api` (or even into its own repo)? > Alternatives > ========= > * apply some of the ideas here to `state/api` rather than in a new repo > * move some or all of `state/api` into a new top-level `api` package -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
