On 1 September 2014 06:40, David Cheney <[email protected]> wrote: > Hello, > > This is an introductory email to explain my upcoming series of pull requests. > > The theme is simple: state must not depend on the api server. > > This is currently not true, state depends on api/params because some > of the api types have leaked into the state package and are being > directly stored in mongo. > > Please speak up if you disagree with this proposal.
Sorry for not replying earlier. I'm just back from a week's holiday. I'm not sure I agree with the thrust of this proposal. The api/params package is not the API server - it's a leaf package defining types that may be used by the API server. Thus state does not in fact depend on the api server. Furthermore, I am not convinced that redefining the same types in different places is a great help. It means there's more maintenance, and more chance of getting things wrong when writing the code to convert between them. Go makes it easy to define a single type that defines the marshaling format for both client and server sides. This seems to me to be a Good Thing. Within a single code base, surely a given version of the API can define the parameters for the client and server side in the same way, for example? What we really want to do here, IMHO, is guard against incompatible changes made to types that are persistently used, whether that's because they're stored in mongo or used to communicate with other versions of the API server. I have thought for a while that, rather than writing more error-prone code (at > 17k LOC, surely the API code is big enough as it is?), it would be good to create a tool that helps us with the underlying problem - incompatible changes made to marshaled types. This would not be too hard - the Go language already has such a tool (see http://golang.org/cmd/api/ ), although it is not currently generally applicable. This could make it possible to provide a much stronger assurance about compatibility, including compatibility between types not defined inside juju-core itself, while keeping the code natural and simple. cheers, rog. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
