Re: Configuration management, revision 3

[Craig Brozefsky <craig@onshore.com>]

Joey Hess <joey@kitenet.net> writes:

> Won't each frontend have to implement it?

Not, it's only a description.  A frontend could be given access to it
in any manner,  You could even write a C interface that returns
structs based on the description, or whatever.

> I think we're going off on a pointless tangent. Let me ask you: how is this
> proposal for a language implemented in the frontend different that the
> original proposal for a shell script that that communicates with the
> frontend? I don't see any significant differences. We've moved the language
> into the frontend and changed the language from shell to something we think
> up, those are the only differences I see.

The shell is not really as expressive a data representation language
as the specialized scheme like language.  Forget for a moment that it
has parenthesis, it doesn't really matter what the syntax is at this
moment. 

> Why don't we then just send the frontend a lump of shell code and use that
> as our implementation language? The only reason I see why not is that then
> the frontend would have to parse the shell code. Well, then, why not make
> there be an interface between the shell code and the frontend (like the one
> originally proposed, say) and the frontend just pasres that? Ok, if there's 
> an interface we can move the shell code out of the frontend and into the 
> backend, and we're back to the original proposal.

But why use shell as a specialized data description language?  Wether
it's some scheme like variant, or something else with ASN.1 or
whatever, your not describing instructions, your describing a peice of
data, a question and an answer.

<... schemish data representation language>

> How is this different from:
> 
> #!/bin/sh -e

<...>

Because one is description of a data entity, and the other is a set of
instructions for getting some string from a user and basically
simulating a protocol.


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org