> I thought this list was about building network wide configuration
> management systems today rather than inventing a new key technology
> that solves "magic" to implement "oracles" tomorrow.
You say tomato. I say tomato. Same denoted things, different
senses.
You object to the terms "magic" and "oracle". Fine. "magic" is
strucken from the vocabulary as a nonce, and "oracle" can be replaced
by "function of specified range and domain", although you should note
that the term "oracle" is often used in subset reasoning like this.
In this case, I specified the approximate range of some of the
oracle functions in prior mail; I neglected fully specifying domain as
"exercise to the reader". If you wish, we could proceed to fully
flesh out whatever systems you like: give me top level specification,
and I will subset the problem specification and can continue to do so
down to very finely granular parts.
I'm here to help you with your problem; part of what I'm here to
tell you is that "networks" are far from the only places that have
this problem with making tractible configuration. You give me
concrete examples (as you have), and I will tell you what I see as it
relates to what I know of the word "configuration" in all its horror.
Perhaps with the help of one another, we can shed light on how to
portably communicate, yes?
If you want me to show you the so called "magic", I can do that
to: present version of the "hard part" is perhaps 80 lines of scheme
that still doesn't say what I want, but is getting there. Writing
proper recursion combinators is Hard, and I am told that this is a
Very Hard recursion combinator to get right. Maybe I can do it.
Maybe I can't. My immediate problem is copious free time to think
about the hard problems.
Getting the hard problems correct is very important for what I
want to do. It may be important for what you want to do; I don't
know. Let me read the particulars of what you just said; you have
good examples.
Follow-Ups:
References:
|
|
