ALFS Communication Design

Gerard Beekmans gerard at
Wed Sep 6 21:13:02 PDT 2000

Nobody knows for sure what the standard is so all views are based on the
person's own view, which is great of course. But it leads to confusion as
well. Because somebody else had a different idea or interpretets things
differently and is confused by somebody elses views.

So let me set a standard now which is not a final standard, but let it be
something that we will work with now. If it proves ill-founded we just have
to change it as we go.

Like I emailed before this is how me bryan and jesse see the communication
between the different parts going. Again, what i write down now is my
interpretation from what bryan and jesse think so I probably have flaws in it.

Again, please know that I don't want push my ideas because I don't like other
ideas. In fact I've read a lot of interesting ideas which are probably better
than what's outlined below. But I haven't been able to give those other ideas
a lot of thought yet. What's below has been thought about quite a bit so I'm
most comfortable with it. I think that's the only reason why I write this.
I'm comfortable with the setup outlined below. But I am still open for
opinions and changes.

The ALFS suite consist of the following 4 components:

1) front-end
2) profile
3) profiler
4) compiler

Who communicates with what?

1) You start an ALFS process by starting up a 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
5) The profiler receives the profile does what it needs to do and feeds
it to the compiler
6) The compiler translates profile into it's own language. Python backend
translate the XML profile into Python language. C++ backend translates XML
into C++
7) Compiler reports back to the profiler on it's status and profiler can
do some error correction and other things that it needs to do
8) When the compiler is done, notify profiler, profiler notifies front-end

I don't think we need to specify the nitty gritty details what a module does
exactly. I think knowing the global communication flow (who talks to what) is
what we need to know right now so that the profile can be based on it.
Example: it's stated that the front-end lets you modify things. That
eliminates the need of <input> xml tags. So now this removal of <input> no
longer is a possiblity: it's a reality.

I can't stress enough that this is just a temporary design. It's a delicate
issue and I know some people will be at least slightly offended by my
seemingly stubornness and not taking other ideas into account. I apologize
for that. So instead me having to wrestle through 80 emails a day to find
different ideas perhaps those people can comment to this email.

Btw, this email was run by Jesse before I sent it out and it has his blessing 
but he already said he's going to pick on it tomorrow after he got some sleep 
(same goes for me).

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

More information about the alfs-discuss mailing list