On 16/09/14 19:19, roger peppe wrote:
> On 16 September 2014 02:12, Tim Penhey wrote:
>> On 12/09/14 01:35, Nate Finch wrote:
>>> Separation of logic is absolutely a good thing. Separation of data is
>>> not nearly so useful.
>>
>> What I see as the real benefit of this work is based behind the
On Tue, Sep 16, 2014 at 7:59 PM, William Reade
wrote:
> On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
>> I don't see how having different identical structs that are updated
>> simultaneously in any way prevents any problems with compatibility.
>
> If we're updating those structs simultaneous
On 16 September 2014 10:59, William Reade wrote:
> On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
>> I don't see how having different identical structs that are updated
>> simultaneously in any way prevents any problems with compatibility.
>
> If we're updating those structs simultaneously, w
On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
> I don't see how having different identical structs that are updated
> simultaneously in any way prevents any problems with compatibility.
If we're updating those structs simultaneously, we're completely
missing the point. Once we've defined a p
On 16 September 2014 02:12, Tim Penhey wrote:
> On 12/09/14 01:35, Nate Finch wrote:
>> Separation of logic is absolutely a good thing. Separation of data is
>> not nearly so useful.
>
> What I see as the real benefit of this work is based behind the
> "interface segregation principle".
>
> Effec
On 12/09/14 01:35, Nate Finch wrote:
> Separation of logic is absolutely a good thing. Separation of data is
> not nearly so useful.
What I see as the real benefit of this work is based behind the
"interface segregation principle".
Effectively this boils down to "don't depend on things you don't
I have been in situations in past jobs where adding one field to one
logical entity required changing the signature of a half dozen structures &
functions that were just copying data back and forth for little to no
benefit. This is a pain in the ass, error prone, and should be avoided.
One of the
On 11 September 2014 06:40, John Meinel wrote:
>> ...
>> 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 chang
>
> ...
> 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 t
On 1 September 2014 06:40, David Cheney 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 ha
On Mon, Sep 1, 2014 at 1:02 AM, Frank Mueller
wrote:
> I absolutely like this approach, John and I discussed more than once about
> it. And as a consequence, in a later cleanup, the API packages have to leave
> the state namespace.
It would also be nice to separate the "public" client from the cl
On Mon, Sep 1, 2014 at 12:05 AM, David Cheney
wrote:
> The goal I have been tasked with is breaking the interdependency
> between the state package and the _client_ api types in
> state/api/params.
Thank you!
-eric
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscri
On Mon, Sep 1, 2014 at 12:03 AM, John Meinel 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 Agen
well, it is both today.
John
=:->
On Mon, Sep 1, 2014 at 11:49 AM, David Cheney
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
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
wrote:
> On Mon, Sep 1, 2014 at 8:03 AM, John Meinel wrote:
>> FWIW I'd favor 3 layers, though it doe
...
>
> 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
On Mon, Sep 1, 2014 at 8:03 AM, John Meinel 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 Agent
On 01/09/14 16:03, John Meinel 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.
>
I absolutely like this approach, John and I discussed more than once about
it. And as a consequence, in a later cleanup, the API packages have to
leave the state namespace. Wouldn't change a lot about the logic, but makes
the separation more clear.
mue
On Mon, Sep 1, 2014 at 8:05 AM, David Chene
The goal I have been tasked with is breaking the interdependency
between the state package and the _client_ api types in
state/api/params.
I don't have any opinion on adding additional layers assuming that
their dependancies flow downwards, ie
labix.org/mgo <- juju/state <- juju/apiserver
On Mon
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.
John
=:->
On Mon, Sep 1, 2014 at 9:40 AM, Dav
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 store
22 matches
Mail list logo
