design of tool

Eric A. Ayer mwalker at ee.pdx.edu
Thu Sep 14 09:16:39 PDT 2000


The other day, I had some ideas on how to program the ALFS tool.  This led
me to start a system design, showing the communication between parious
parts of the system and generally how they interact.  The one problem that
I was unable to figure out was how to allow for user interaction, and the
problem is basically when does the interaction take place.

For example, one idea that had been discussed was to allow the user to
tweak each profile.  Variables could be changed, commands could be added,
and the profile saved as a midified version.  In my system diagram, the
front end would send a profile to the profiler (I called it the ALFS tool
in my design doc - more later), which would translate the XML code to
program calls, and then execute those.  If the user is to edit the
commands at that point, it would not be possible to save the changes back
in the profile - or damn hard - because the changes in the shells commands
would have to be un-interpreted, and the resulting profile saved.  In
addition to that problem, the profiler would then be dealing with user
input (and output), which could really mess up whatever the front end is
doing for a display.  Text printed to stdout would be printed to where
ever the cursor happens to be (if ncurses, that may cause havoc, I'm not
sure).

One solution is to have all the editing done in the front end.  The other
that I see is to create some form of communication between the front end
and the profiler, which will be active between the programs as they both
run.  Two things cause me to lean HEAVILY toward the first option: The XML
code is very similar to the actual commands - close enough that editing it
would be a lot easier and saveable.  The second is that creating the
communication between both layers - especially if the front end is a
seperate program - will make the code a (decimal) order of magnitude or
two more complex.  That is not needed.

Wednesday, the 13th, I cornered HIghoS on IRC and tried to get this
straight.  Of course, since this hadn't been worked out previously, he
could not just give me the answer, and didn't want to bypass the rest of
the group.  Because of that, I am posting here, including my design
document as it stands.

I will continue to work on this.  My intention is to get a tool working,
not
including the front end, that will execute the profiles.  Once I have it
done, I'll post the source to the list.  Everybody can then say it sucks
and do something entirely different, but I hope that at least some part of
my design or implementation will do some good somewhere.

Anyway, here is the design doc.  It's in MS word format, which I used
because I don't have star office installed right now and needed something
that I could do at least primative diagrams on.

					-Erik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: alfs-tool.doc.bz2
Type: application/octet-stream
Size: 9652 bytes
Desc: 
URL: <http://lists.linuxfromscratch.org/pipermail/alfs-discuss/attachments/20000914/4110980b/attachment.obj>


More information about the alfs-discuss mailing list