xml structures and some notes
gerard at linuxfromscratch.org
Wed Sep 6 20:12:32 PDT 2000
> The way I see it: the front-end is communicating to the backend. So the
> front-end is the dumb tool, while the backend is the smart one. Also, you
> HAVE to use some way to tell the backend what is optional, what can be
> changed, what different ways there are to do things. So you need special
> tags to do this. We're not (at least, we SHOULD not) use tags like
The idea was to do it this way. It might prove not to be the best way but
this is how things are beeing looked at at the moment:
The ALFS suite consist of the following 4 components:
How do they interact?
1) You start an ALFS process by starting up the front-end
2) The front-end asks you to choose a profile
3) The front-end asks you to change things
4) The front-end feeds the modified profile to the profiler in chunks (one
section at a time)
5) The profiler receives the section and feeds it to the compiler who
executes whatever needs to be done
6) Compiler reports back to the profiler on it's status and profiler can do
some error correction and other things that might be needed
7) when a section has completed, profiler notified front-end
8) front-end then feeds second section to the profiler and we go back to step
Why per section? You might want to change every section on-the-fly. Or during
the install. of section 1 you can modify later sections. Those are just
details but we want to be flexible.
Now I'm writing this why not take the profiler step out of it and make the
Or keep it this way; makes it easier to create a lot of different front-ends
without having to worry about them error correcting.
IT's getting late and I'm realy having a hard time keeping track of
everything on this list the past few days.
It'll die down in a bit, I'm sure. Then we start summarizing things and we'll
figure it out.
-*- If Linux doesn't have the solution, you have the wrong problem -*-
More information about the alfs-discuss