Processing commands for [EMAIL PROTECTED]:
> severity 80347 normal
Bug#80347: [PROPOSED] allow/document use of Debian Configuration management
system (debconf)
Severity set to `normal'.
> retitle 80347 [AMENDMENT 2000/12/26] allow/document use of Debian Configura=
Bug#80347: [PROP
severity 80347 normal
retitle 80347 [AMENDMENT 2000/12/26] allow/document use of Debian Configuration
management system (debconf)
thanks
This proposal's been seconded by myself and Raul since the 26th, documents
existing practice, and hasn't generated any particular objections,
so pres
Anthony Towns wrote:
> > + `templates' file in their control archive. The `config' script may
>^^^
> "*can* be run before the preinst", would probably be better: we're
> just describing what can happen, not using the "must/
On Fri, Dec 22, 2000 at 03:26:50PM -0800, Joey Hess wrote:
> --- tmp/policy.text Fri Dec 22 14:05:33 2000
> +++ policy.text Fri Dec 22 14:05:24 2000
> +2.3.9. Prompting in maintainer scripts
> +--
> + Packages which use the Debia
of redundant prompting, consistency of user interface, etc.
>
> I feel that with this increasing number of packages using debconf, plus
> the existance of a nascent second implementation of the Debian
> configuration management system (cdebconf), and the stabalization of the
> prot
Anthony Towns wrote:
> Versioned provides won't be available for a while (they completely break
> apt 0.3, not sure if apt 0.4 supports them), so that'll break cdebconf,
> and mean the only possible implementation of the `Debian Configuration
> management specification'
.
Versioned provides won't be available for a while (they completely break
apt 0.3, not sure if apt 0.4 supports them), so that'll break cdebconf,
and mean the only possible implementation of the `Debian Configuration
management specification' is debconf. And, again, it limits how w
amend that line to:
+ using only tools present in essential packages. [footnote]
+
+ [footnote] Debconf or another tool that implements
+the Debian Configuration management specification
+will also be installed, and any versioned
+dependancies
Anthony Towns wrote:
> > + using only the tools present in the base system.
> ^^^
>
> ...which might be uninstalled whenever the user might wish. The "required"
> packages are a better match, although that priority seems a bit flakey
> too, a
iner scripts
> +--
> + Package maintainer scripts may prompt the user if necessary. Prompting
> + may be accomplished by hand, or by communicating with a program,
> + such as debconf, which conforms to the Debian Configuration management
> + specificatio
preconfiguration, (mostly) noninteractive installation,
elimination of redundant prompting, consistency of user interface, etc.
I feel that with this increasing number of packages using debconf, plus
the existance of a nascent second implementation of the Debian
configuration management system (cdebconf), and
It seems to me there are about 3 very separate and distinct issues
which people are confusing here. They are:-
1. Separating non-interactive and interactive configuration of packages
somehow.
2. Making some kind of persistent storage manager for package configuration
data.
3. Making some k
Le Wed, Nov 11, 1998 at 02:13:56PM +0100, Wichert Akkerman écrivait:
> Sorry to say this, but this is complete and utter nonsense. The only
> difference was if you used a virtual database that can consist of
> multiple sources or a single database. How you access that database
> is the same for bot
Previously Raphael Hertzog wrote:
> Read Ian's argument. This design make it difficult to say : "Now I
> want to remove all mail-transport-agent/* keys".
Sorry to say this, but this is complete and utter nonsense. The only
difference was if you used a virtual database that can consist of
multiple
Le Wed, Nov 11, 1998 at 02:18:56AM +0100, Wichert Akkerman écrivait:
> Why? This is a lot less flexible imho. And it does not reduce the
> complexity (read my design again).
Read Ian's argument. This design make it difficult to say : "Now I
want to remove all mail-transport-agent/* keys".
And the
Previously Raphael Hertzog wrote:
> I agree with Ian that each machine should have only one database,
> possibly none too (think about a remote db).
Why? This is a lot less flexible imho. And it does not reduce the
complexity (read my design again).
> The DB access should be done through a progra
Hello,
i've read many mails in the archive in order to make me an opinion
about the configuration management system discussed here.
The orientation is good I think. But the proposed implementation
is IMHO too much complicated. Here's a list of my thoughts on
various points of the p
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
fix that user interface. lots of people will want to unpack a software, look
at the description, files, man pages, docs, and then decide whether t
Previously Raphael Hertzog wrote:
> And it's the second part that we want to change in order to allow
> non-interactive installation. But if we do not clearly
> separate the first part from the second the only way of
> non-interactive install will be to use the configuration database.
Of course n
> > Shouldn't we create with all this a `Linux registry' (sorry, but the
> > structure is very similar to the Windows one).
> > The `Linux registry' would be offered, through an API, to software
> > developers and other distributions, so there would be softeare enterely
> > configured with this r
Le Wed, Oct 21, 1998 at 01:44:43PM +0100, Ian Jackson écrivait:
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
Yes, my first mail had no sense if we consider it that way... let me
explain a bit
Previously Ian Jackson wrote:
> In Debian, running the postinst script _is_ configuring the package.
> If you want to install a package but not to configure it, use
> dpkg --unpack.
Indeed. The design even has a way of preconfiguring systems:
you can put configuration in a remote database and tell
Raphael Hertzog writes ("Configuration management goal"):
...
> I think we have jumped over a step : the configuration is managed in the
> postinst script. But most package does not clearly separate
> post-installation from configuration. And this difference should really
&g
Hi,
i've just subscribed to -policy but I read some mails in the archive about
configuration management. The configuration management thread has started
with the need of a non-interactive installation process, I believe.
We are now talking about a big registry containing the informations n
Shouldn't we create with all this a `Linux registry' (sorry, but the
structure is very similar to the Windows one).
The `Linux registry' would be offered, through an API, to software
developers and other distributions, so there would be softeare enterely
configured with this registry.
This message is partly summary of my understanding of the state of the
discussion, partly an attempt to describe my own world model, and
partly an attempt to convince people to do some things my way.
1. DATA MODEL
We seem to be agreed that the data stored will be a set of name->value
pairs. We b
On Tue, 18 Aug 1998, Joey Hess wrote:
> Jason Gunthorpe wrote:
> > For simple packages I (the user) probably do NOT CARE what they configure
> > themselves to be. I have no interest in mime-type configuration, no desire
> > to do things with my mailer or apache. I just want them to work and I
> >
Jason Gunthorpe wrote:
> For simple packages I (the user) probably do NOT CARE what they configure
> themselves to be. I have no interest in mime-type configuration, no desire
> to do things with my mailer or apache. I just want them to work and I
> don't want to be bothered because I have nothing
e nothing to tell them.
99% of all packages should require very, VERY minimal configuration but
on the flip side packages should be highly configurable and have lots of
questions! The goals conflict :>
> IV. What `types' of the configuration data are there ? Is its type
> stored in th
le is supplied, ask
all supplied variables. Otherwise do that from a (post|pre)inst'
> IV. What `types' of the configuration data are there ? Is its type
> stored in the database of answers ?
>
> It's entirely unclear to me that anything except the user prompting
> part of
e to replace the
current programs like slrnconfig, smailconfig, etc, with similar programs
thatuse the config manager. If they are run standalone, they run the config
manager, if run from the postinst, the config manager will already be running.
> IV. What `types' of the configuration data
What `types' of the configuration data are there ? Is its type
stored in the database of answers ?
It's entirely unclear to me that anything except the user prompting
part of the configuration management system (which has to be invoked
with the names of the data entries et al available) needs
Martin Oldfield wrote:
> Joey> The proposal is that would use /emacs19/ for stuff local to
> Joey> it, as well as /news-reader/ and /mail-reader/ for stuff
> Joey> that.is shared with other news and mail readers.
>
> So in what sense is that a hierarchy ?
That only describes the root
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Martin Oldfield wrote:
>> I think there are problems with a hierarchy, exemplified by
>> emacs which contains both a newsreader and a mail program. I
>> suggest that this implies the hierarchy either needs to provide
>
Martin Oldfield wrote:
> I think there are problems with a hierarchy, exemplified by emacs
> which contains both a newsreader and a mail program. I suggest that
> this implies the hierarchy either needs to provide multiple
> inheritance, or is replaced by a simple list of the bits of the space
> wh
> "W" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
--> snip <--
W> 1. The configuration space All configuration information is
W>stored in what I
W> call the configuration space. This is a database with a special
W> design which resembles to method we look at configurat
Previously Joey Hess wrote:
> I think we should at least have a default priority.
I reached the same idea, and added it back to the text I keep at home.
I also changed the INPUT command to remove the priority-parameter and
added an UPDATE-command to change the priority (or other aspects) of a
vari
Previously Joey Hess wrote:
> Can't we just use postinst scripts for this? Just keep track of what package
> owns which variables, and when a variable in apackage changes, re-run the
> postint (which will presumably act on the change).
We could, but that's just a trivial implementation of a trigge
> Stephen Zander <[EMAIL PROTECTED]> wrote:
> > I was going to comment that this screams SNMP/MIB to me, until
> > I noticed that you mentioned this later on. Without leaping to
> > implementation ahead of design, wouldn't explicitly using an SNMP
> > approach reduce the work involved here (eg no n
Stephen Zander <[EMAIL PROTECTED]> wrote:
> I was going to comment that this screams SNMP/MIB to me, until
> I noticed that you mentioned this later on. Without leaping to
> implementation ahead of design, wouldn't explicitly using an SNMP
> approach reduce the work involved here (eg no need to re-
Raul Miller wrote:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > > Finally, I don't think we can completely get rid of interaction
> > > with the user at install time.
> >
> > I think we can.
>
> You think we can safely toss the "Are you sure?" prompts?
We can do the "are you sure" prompts in the c
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> 1. The configuration space All configuration information
Wichert> is stored in what I call the configuration space. This is
Wichert> a database with a special design which resembles to
Wichert> method we look a
Joey Hess <[EMAIL PROTECTED]> wrote:
> > Finally, I don't think we can completely get rid of interaction
> > with the user at install time.
>
> I think we can.
You think we can safely toss the "Are you sure?" prompts?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "
Wichert Akkerman wrote:
> Previously Bernd Eckenfels wrote:
> > I would think something needs to export the new value into
> > /etc/news/servers. Since it is not possible to reconfigure running news
> > servers anyway.
>
> I don't really care what changes waht file at, I'm more interested in the
Jason Gunthorpe wrote:
> > 4. How do the configmodule and the frontend interact?
> > Of course the configmodule and the frontend must exchange data to do their
> > work. We do this in a very simple manor: dpkg starts both the configmodule
> > and the frontend, and connect the stdin/stdout from the
Wichert Akkerman wrote:
> * all proposals for a file with the variable list share 1 thing: the priority
> of a variable is given in this list. I don't think that is reasonable
> though:
> we can't always know if a variable is important until we know the
> conditions.
> For example: if you c
Previously Bernd Eckenfels wrote:
> I would think something needs to export the new value into
> /etc/news/servers. Since it is not possible to reconfigure running news
> servers anyway.
I don't really care what changes waht file at, I'm more interested in the
design that makes this possible. Tri
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> Raul> Note that most packages do not require such a state machine.
>
> True, although I note the obvious fact that this is a special case of
> a state machine with a simple transition matrix: if the verification
> script returns 0 on OK, and -1 on e
Raul Miller wrote:
> I'm not convinced that installation scripts are the right place for
> packages which do require such complicated configuration. As a
> general rule, when configuration gets that complex you're going to
> want to use the same tool for reconfiguration.
This is why many of the c
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
--> Joey's comments snipped <--
Raul> Note that most packages do not require such a state machine.
True, although I note the obvious fact that this is a special case of
a state machine with a simple transition matrix: if the verificatio
Joey Hess <[EMAIL PROTECTED]> wrote:
> That's actually a good summary of where I think we're headed. However, I
> think you need to allow each package to provide a state machine. We need this,
> becuase there's no way some generic state machine is going to be able to
> present the data to the user
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Hmm, unless we give each variable a default-priority and make it
> possible for the script to change it.
Ok.
> That's not what I meant. If someone uses SNMP to change (for example)
> to change the NNTP-server we should use, something needs to act upon
On Sun, Aug 02, 1998 at 03:42:09PM +0200, Wichert Akkerman wrote:
> That's not what I meant. If someone uses SNMP to change (for example)
> to change the NNTP-server we should use, something needs to act upon
> that change to reconfigure all newsreaders to use that new host.
I would think somethin
Previously Martin Oldfield wrote:
> This is a bit like the much criticized default mechanism in X. Are
> there lessons to be learnt from that ?
Yes, it's way to easy to create a mess. You get people stuffing
everything in the root to override stuff, or someone who puts
something in the root by acc
Previously Jason Gunthorpe wrote:
> I continue to advocate that this creates the wrong sort of 'UI experiance'
> for the user. They are forced to run each script in some arbitary
> sequence and each package must provide such a script even if they only
> need some trivial manipulations. We need to
On Sun, 2 Aug 1998, Wichert Akkerman wrote:
> the preinst, and before the package is unpacked! Unless pre-depends are
> used, this will mean that the module can only assume the base-system is
> installed.
No, it can be called before the package is unpacked, pre-depends mean
-NOTHING- it can only
Previously Antti-Juhani Kaijanaho wrote:
> On Thu, Jul 30, 1998 at 01:45:18AM +0200, Wichert Akkerman wrote:
> > I was thinking about a language which seperates the two: first you
> > declare all variables you want to use and give each a priority. In the
> > next section you state dependencies bet
Martin Oldfield wrote:
> Isn't the obvious generalization to divide configuration questions
> into blocks, then specify a state machine to navigate between blocks ?
>
> I think it would be good tohave a very general verification mechanism:
> were we to implement this in perl, then we could just pr
On reflection I think you're right, it's not clear the inheritance
buys much save extra complexity. It was only a flippant comment.
How does it all work if there's a simple list of sources of data in a
file in /etc/ where that machine looks for config stuff ? A simple URL
probably works well and a
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> configurations there I wonder ;*) More seriously I think an
> inheritance hierarchy is a better model.
Better than what?
Inheritance is a mess when you don't sit down and carefully design the
system ahead of time. And, frankly, I don't think that prov
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Martin Oldfield <[EMAIL PROTECTED]> wrote:
R> Er, if you don't mind that you have a nondeterministic state
R> machine (for example: all possible states exist in parallel)
R> when you're describing the configuration for m
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> R> Er, if you don't mind that you have a nondeterministic state
> R> machine (for example: all possible states exist in parallel)
> R> when you're describing the configuration for many machines.
>
> Is this the right way to think about it ?
> "R" == Raul Miller <[EMAIL PROTECTED]> writes:
R> Martin Oldfield <[EMAIL PROTECTED]> wrote:
>> Isn't the obvious generalization to divide configuration
>> questions into blocks, then specify a state machine to navigate
>> between blocks ?
R> Er, if you don't mind that y
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> Isn't the obvious generalization to divide configuration questions
> into blocks, then specify a state machine to navigate between blocks ?
Er, if you don't mind that you have a nondeterministic state machine
(for example: all possible states exist in p
Isn't the obvious generalization to divide configuration questions
into blocks, then specify a state machine to navigate between blocks ?
Within a block a series of questions are specified which are passed to
some front end which interogates the user. Within block questions
aren't ordered; I ima
Previously Jason Gunthorpe wrote:
> > I strongly suspect that if we take a carefull look at what the
> > configuration scripts are asking we will find this is not a major hurdle
> > for MOST things - and a such should not be the central focus of any
> > proposal.
Wichert Akkerman <[EMAIL PROTECTED
Antti-Juhani Kaijanaho wrote:
> Does this help at all?
Yes, I understand where you're coming from.
> You just found the first genuine bug in my idea. Congratulations. It
> is not fatal, however. Here is one way of fixing it. If you need to
> have one set of questions or another set if questio
On Thu, Jul 30, 1998 at 04:08:59PM -0700, Joey Hess wrote:
> Antti-Juhani Kaijanaho wrote:
>
> I don't understand the meaning of "decisions" you are using.
I'm talking about the decisions over what actually gets asked.
Unfortunately no RFC describes a protocol for transferring thoughts
from one'
Antti-Juhani Kaijanaho wrote:
> There is a fundamental difference. The new model allows the frontend
> make the decisions, based on the constraints set by the package's
> configmodule. In the original model the decisions were hardwired into
> the configmodule, and if you wanted to change the deci
On Thu, Jul 30, 1998 at 01:05:55PM +0200, Ronald van Loon wrote:
> How about XML ? It's rather easy to parse, to extend etc. Just
> define a bunch of tags and attributes, and le voila. Done.
On the one hand, as XML is a metalanguage, you would still be defining
a new language. No gain from that p
On Wed, Jul 29, 1998 at 05:01:54PM -0700, Joey Hess wrote:
> 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?
There is a fundamental difference. The new model allo
On Wed, Jul 29, 1998 at 10:56:46PM -0700, Joey Hess wrote:
> It already has if statements.
No, no, no, no, no!
The language I described doesn't have any statements at all, not if
statements nor any other statements. You would need a flow of control
for having statements. But no flow of control
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
> I realize that this language requires a more sophisticated parser than
> Akkerman's original, but IMO it would be worth it. And I don't think
> the parser needs to be /that/ sophisticated :-)
Mmmm. Prefix syntax (best Homer Simpson drooling no
On Thursday, July 30, 1998 12:46 PM, Antti-Juhani Kaijanaho
[SMTP:[EMAIL PROTECTED] wrote:
> On Thu, Jul 30, 1998 at 10:05:53AM +0100, Martin Oldfield wrote:
> > Rather than writing yet another language why don't we just use an
> > existing one ? Whilst it's true that you don't want to force a use
On Wed, Jul 29, 1998 at 04:21:59PM -0700, Joey Hess wrote:
> You've just re-invented lisp. ;-)
No I haven't. The syntax I used is similar to Lisp, on purpose. And
I did mention it. However, on a production system, the syntax need
not be Lisp-like, I just used it because I had to pick a syntax f
On Thu, Jul 30, 1998 at 10:05:53AM +0100, Martin Oldfield wrote:
> Rather than writing yet another language why don't we just use an
> existing one ? Whilst it's true that you don't want to force a user to
> learn say perl just so that he can write his software, it's surely
> better that he learns
> "Antti-Juhani" == Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
--> snip <--
>> Even if the parser is (somewhat) complicated, we only need to
>> implement it once.
Antti-Juhani> Right. It should be put in a shared library IMHO.
Antti-Juhani> Oh, and BTW, I think this
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
-> snip <-
Joey> use mail-reader, strn an nn could use news-reader). This
Joey> shared tree can also be used as a default, ie a variable
Joey> ! news-reader/nntpserver can be used by strn if
Joey> strn/nntpserver does not
Antti-Juhani Kaijanaho wrote:
> > I was thinking about a language which seperates the two: first you
> > declare all variables you want to use and give each a priority. In the
> > next section you state dependencies between the variables and possibly
> > a decision process.
>
> Yes! This is how
On Thu, Jul 30, 1998 at 01:45:18AM +0200, Wichert Akkerman wrote:
> (nesting example removed)
It wasn't a nesting exmple. :-)
> I was thinking about a language which seperates the two: first you
> declare all variables you want to use and give each a priority. In the
> next section you state de
27;ve also worked in some
suggestions from others. Changes are marked with "!".]
Configuration Management
Managing configuration data
===
1. The configuration space
All con
Craig Brozefsky wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
> > It already has if statements. Richard said he wanted to add some stuff to
^ Wichert, not Richard. oops
> Agreed. I think it's a bit on the complicated side already. I was
> answering your questi
Joey Hess <[EMAIL PROTECTED]> writes:
> It already has if statements. Richard said he wanted to add some stuff to
> make it more complex. At some point it stops becoming a representation and
> becomes a turing-complete language and then you're no better off than you
> were before.
Agreed. I thin
Jason Gunthorpe wrote:
> I don't see why shell can't be used, so long as it provides the
> flexability we are looking for..
>
> How would the shell script be sent to the user? We can put the value tree
> inside a file on the ftp site, but a script could be quite large+complex..
I wasn't proposing
Craig Brozefsky wrote:
> 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.
It already has if statements. Richard said he want
At 15:02 -0700 1998-07-29, Joseph Carter wrote:
>Seems like the thing to do is agree to and adjust policy such that preinst
>does not interrupt the process (ie, no prompts) and modify dpkg to support
>--unpack-only or similar..
dpkg already has --unpack
--
Joel "Espy" Klecker
mailto:[EMAIL PROTECT
On Thu, 30 Jul 1998, Joseph Carter wrote:
> On Wed, Jul 29, 1998 at 06:15:54PM -0600, Jason Gunthorpe wrote:
> > > In the case of predepends, I have no idea what to do. But if all the
> > > postinst that could be was saved till after everything else was done, you
> > > just come back to the mach
On Wed, 29 Jul 1998, Joey Hess wrote:
> > Look at it from a broader perspecive, how will a Pre-Configuration GUI
> > look for N packages, what options will the user have, how will they
> > interact with it? Do you envision a simple series of prompts or as some
> > sort of exploritory tool allowin
On Wed, Jul 29, 1998 at 06:15:54PM -0600, Jason Gunthorpe wrote:
> > In the case of predepends, I have no idea what to do. But if all the
> > postinst that could be was saved till after everything else was done, you
> > just come back to the machine and answer remaining questions...
>
> APT alrea
Joey Hess <[EMAIL PROTECTED]> 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 po
A while back in this thread I asked if there was some way a "back" button
could be implemented to return to previous questions in a configuration
script. Here's one way to do this - this is a modification to Wichert's v3
propsal:
After each GO command, the frontend should return a result status
Joey Hess wrote:
> This latter obviously is more what we want. My point was that neither
> Wichert's proposal nor Antti-Juhani Kaijanaho's proposal accomplish this.
Forgot to add, I think the way to make Wichert's propsal implement this is
simply to break out a control file that lists all the valu
Jason Gunthorpe wrote:
> The distinction doesn't have make much difference when you look at a
> single package, who cares if it pulls or pushes, it does it's query thing
> and then it's done - either way it works.
>
> Look at it from a broader perspecive, how will a Pre-Configuration GUI
> look fo
On Wed, 29 Jul 1998, Joey Hess wrote:
> 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 betwe
On Wed, 29 Jul 1998, Joseph Carter wrote:
> Seems like the thing to do is agree to and adjust policy such that preinst
> does not interrupt the process (ie, no prompts) and modify dpkg to support
> --unpack-only or similar.. Then apt just needs to sort out predepends.
> Predepends are the only
On 29 Jul 1998, Miquel van Smoorenburg wrote:
> Hmm, has noone in this thread mentioned COAS yet? http://www.coas.org/
> It is ment to be a complete Linux administration package, with plugin
> modules for every package. If we just provided the configuration
> module with each package, COAS could
Wichert Akkerman wrote:
> I happen to like playing around with parsers and compilers. I'll see if
> I can come up with a nice design :). Even if the parser is (somewhat)
> complicated, we only need to implement it once.
Won't each frontend have to implement it?
I think we're going off on a pointl
Previously Antti-Juhani Kaijanaho wrote:
> Let's start with a very simple package, xyzzy. The only thing it
> needs to know is whether the system clock is set to UTC or not.
> How to present this to the frontend? Clearly we need to give it a
> named aggregate of pairs (consisting a label and a
Previously Miquel van Smoorenburg wrote:
> Hmm, has noone in this thread mentioned COAS yet? http://www.coas.org/
Actually, I have. COAS has some drawbacks: it's development is seems
very slow, the mailinglist has no messages except for people complaining
about how to compile it, and it needs all
Antti-Juhani Kaijanaho wrote:
> You just have to design the language to be flexible enough. In this
> post I'll sketch one.
> (datum metoo/foo
> (type yesno)
> (query "Do you want me to do foo?")
> (default yes))
> (if (yes? metoo/foo)
> ((datum metoo/foo2
> (type yesno)
..
You've
1 - 100 of 133 matches
Mail list logo
