Re: CONS specs update?

[Pierre THIERRY]

> I'd hate to see yet another effort to revive Cons drop flat. 

So do I. Sorry for the very long silence, I didn't find time to sit on a
table with a notepad, and think about how everything the discussed about
could fit together. I think I was lacking inspiration to do the
synthesis of that...

But the inspiration came, at last, thanks to my readings about semantic
web, and RDF.

I think that there is a very simple way to achieve the nearly-AI and
moudlar CONS we talked about. Here is how I sum up the thread.

CONS, to build something, needs:

- a dependency graph, describing what the parents of each file or group
  of files are, and the steps (processes) needed to build the file(s)
  with their parents,
- the build steps can (should) be separated from this dependency graph,
  and consist of a (big) set of very small graphs,
- all the source files that are needed to build a complete graph
  pointing to the wanted resulting file(s),
- all the build tools needed in the various build steps.

So, in fact, and that was what was blocking me, the various CONS modules
just need to be able to communicate graphs and trigger commands.
Trivial, isn't it?

And for what I know, RDF is just the most complete and practical (and
widespread...) way we have today to represent relations between objects.

So here are the core modules of CONS:

- Builder: given fully-constructed dependency and steps graphs, it
  triggers the modules that can handle the steps of the dependency
  graph,
- Local-Command: given a fully-constructed step graph involving only
  commands locally present on the computer and the source files, it
  triggers the commands,
- Remote-Command: given a fully-constructed step graph involving only
  commands remotely present on a computer and the source files, it
  triggers the commands.

We need at least the following optional modules:

- Construct: it provides a Perl API to construct a dependency or step
  graph.

Then, we would be free to implement whatever existing or desirable
module the way we want, and in the programming language we prefer,
because we have an independant communication protocol. This could
include the guessing system, and improving the builder. I see two major
possibilies: if the standard one does not build in parallel (it would be
a shame if it doesn't, but it could be easier to implement a very
trivial one at first), a Parallel-Builder module could replace it, and
we could imagine a Fast-Parallel-Builder module, that would be able, for
example, to estimate the time needed for some steps, and would execute
the steps in such an order that the builds is performed faster...

Everything is possible.

Does someone has objectons about the use of RDF for dealing with graphs
communication, and the modular design I describe here?

Nowhere man (aka le Moine Fou, having changed nick and email inbetween)
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature