<div dir="ltr">So 'params' lives in 'api' because both client code and server side code uses it (api.Client exposes params for many of its methods, I believe).<div>That may be a signal of a different problem, but there is a fair amount of code (eg worker) that makes use of api/params, and it makes more sense to have that in 'api' than in 'apiserver'.</div> <div>Now it might be that we have a clearer indication we're doing something wrong, but certainly what *worker* code sees needs to be in api.</div><div>Certainly almost all of those objects acts as in and out side of the api, though I would be reasonably ok if that meant they were in apiserver.</div> <div>I'm less happy for things that are exposed outside of api to be in apiserver.</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 1:05 PM, William Reade <span dir="ltr"><<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@canonical.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div> <br></div><div>I think the most important actions are:</div><div><br></div><div> * move state/api/params under state/apiserver</div><div> * move state/apiserver to the top level, and make sure it's clearly documented</div> <div><br></div><div>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.</div> </div></blockquote><div><br></div><div>Just to be clear, I've used the term "agent" vs "user" or "client" here. I believe you're distinguishing the client-side of Agent facades (as internal clients) vs the client-side of User facades (like Client, KeyManager, etc).</div> <div><br></div><div>We also have the top level "juju/api.go" which is actually our entry point (where juju.NewAPIClientFromName et al exist).</div><div>I would certainly be happy to see those things consolidated.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> <div><br></div><div>(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.)</div> <div><br></div><div>Cheers</div><span class="HOEnZb"><font color="#888888"><div>William</div></font></span></div></blockquote><div><br></div><div>When you say protocol level, do you mean the "rpc" package, or are you talking more about the actual definitions of the API (what methods are on Client, etc.)</div> <div><br></div><div>John</div><div>=:-></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div> <br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 10:01 AM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 27 June 2014 07:51, David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>> wrote:<br> > On Fri, Jun 27, 2014 at 4:21 PM, John Meinel <<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>> wrote:<br> >> Just my quick thought, I think moving it out from "state/api" into just a<br> >> top level "api" would be reasonable and a lot less clumsy than trying to<br> >> pull it out into an entirely separate repository.<br> ><br> > +1<br> ><br> > I don't think the api package is useful outside Juju (at this time)<br> > and splitting it into another repo just doubles the amount of work.<br> <br> Do you mean that the API package isn't useful *from* outside Juju,<br> or that the API package isn't useful *independently of* Juju?<br> <br> If the latter, I totally agree (the whole point is that it integrates with Juju)<br> but if the former, I disagree. If we are to allow any external Go programs<br> that use Juju (and I think we should - we should act as good citizens<br> in the Go ecosystem) then the API package is the only way to do it.<br> We shouldn't force people to write their own API interface just because<br> we're not prepared to support our own.<br> <br> BTW, I think it would be a good idea to split off the agent parts of the API<br> from the client parts - the former should not be considered public.<br> <br> --<br> Juju-dev mailing list<br> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br> </div></div></blockquote></div><br></div> </div></div><br>--<br> Juju-dev mailing list<br> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br> <br></blockquote></div><br></div></div>