well, it is both today. John =:->
On Mon, Sep 1, 2014 at 11:49 AM, David Cheney <david.che...@canonical.com> wrote: > Thanks William, > > On a related note, I'm also planning on moving api/params to > apiserver/params; these are the server's parameters, not the client's. > > On Mon, Sep 1, 2014 at 5:12 PM, William Reade > <william.re...@canonical.com> wrote: > > On Mon, Sep 1, 2014 at 8:03 AM, John Meinel <j...@arbash-meinel.com> > wrote: > >> FWIW I'd favor 3 layers, though it does mean you have to do copying > between > >> structs that would likely otherwise be almost identical. A State layer > for > >> saving in the DB, an API layer for communication, and a Model layer for > use > >> in the Agents/Clients. > > > > Yes please, in general: one set of types per layer boundary. > > Independent of what Dave's doing, which is necessary regardless, I > > agree with what you're saying: *except* that I think we really have to > > consider the API layer to be *two* layers. > > > > That is to say: if you can change some type in api/params and > > everything still works, you are Doing It Wrong. We cannot depend on > > servers and clients always running the same version -- so, every time > > you thus change server/client in a single motion, you're almost > > certainly introducing more or less subtle incompatibilities. > > > > So, I would be very pleased if we would stop using the same > > definitions (ie api/params) on both sides of the wire -- it's one of > > those things that's nice and easy when everyone's running the same > > version, but an active trap as soon as multiple versions exist (as > > they do). > > > > All the struct-copying is kinda boring, but the layering violations > > are straight-up evil. > > > > Dave, thanks very much for doing this. > > > > Cheers > > William >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
