> Hm. we may be talking about different things. The main way that Bcfg2
Oh, I see I think. Forgive my ignorance.
> differs from LCFG is that a more complex model is built into the wire
> protocol. Basically, the configuration specification language
> semantics are well defined over the wire. This means that any
> configuration source can build representations of the target
> configuration state in those terms, and an application neutral
> deployment engine can interact with them in a meaningful way. So in
> terms of that end of the system, I think that I agree with you.
>
> What I was describing in the last mail was a set of specification
> languages that get composed into client configuration (with the
> previously mentioned semantics). We are finding that it is convenience
> to represent the server-side specification in more domain specific
> terms. We did this because it seemed like a convenient mechanism to
> simplify what users interacted with on the server side. I think (in
> the medium term [I can hear Ed groaning when I say this is only medium
> term and not sooner]) we will move to a smaller set of (or potentially
> single) specification language(s).
I think we're in agreement once again, at least as far as server
side specification. I'm pretty sure that I want to be speaking to my
domain in terms that mean something to my domain, and not the x86
opcodes that imperate what I must say to my domain. Once we admit
that it's reasonable that I speak to my domain in x86 opcodes, why
mince and complain about minor impedence mismatches?
I might be reading what you say very poorly tho.
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
