State should not depend on the API server

[John Meinel]

well, it is both today.

John
=:->



On Mon, Sep 1, 2014 at 11:49 AM, David Cheney <david.cheney at 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.reade at canonical.com> wrote:
> > On Mon, Sep 1, 2014 at 8:03 AM, John Meinel <john at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140901/2f2c307d/attachment-0001.html>