[RFC] profile editing within nALFS: how much do you really want it?
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Mon Mar 15 07:41:14 PST 2004
Hui Zhou wrote:
> Sorry if you find me too lazy to go to the source. Could you give some
> more detailed info on how the profile is actually stored in the
> hadlers? I would appreciate it if you will use a simple example.
Sure, as an example, src/handlers/stage.c, the variable_attribute()
function. In the past, when the profile was being executed, the
<variable> element's attribute were inspected to see if there was a
"mode" attribute, and if it consisted of "append" or "prepend" then the
appropriate action was taken. If it existed but was not one of those two
choices an error was generated and the profile stopped executing.
In the new system, this semantic checking happens at parsing time, not
at execution time. This means that you will get the warnings/errors as
soon as you load the profile, and won't be surprised later when you're
halfway through your profile executing to find out you made a typo.
However, the implementation of this means that the variable_attribute()
function does not actually store the "mode" attribute's contents at all;
once it has determined that there is a valid value present, it parses it
and stores a value in an enum variable to tell it what to do at
execution time (replace, append or prepend).
> Indeed, that is the only advantage. The benefit is the program can
> remember all the flags, to save a user a lot of resetting the marks
> during a try-and-error test run. (When the profile is huge, navigating
> the tree is quite some labor if one have to do it again and again.)
This stuff (saving run-marks and such) will be happening in the nALFS
frontend at some point in the near future.
> Another benefit may be the program can tell user the editing error
> right away. My experience is when I am writing custom profiles, I
> almost wasted more than half of the time just restarting nALFS,
> navigating the profiles, eliminating syntax errors. But I didn't use
> any proper xml editor or validating tool, so it may not apply to
This is very important: usage of xmllint can help you greatly, because
the majority of the syntax errors will be caught before you ever start
nALFS at all. With nALFS' new semantic error checking, another group of
errors will be caught when you load the profile. These two changes will
drastically reduce the amount of time you spend getting your profile to
parse properly before trying to execute it.
> 1. Reimplement the simple edit function. It doesn't need to edit the
> xml source directly, but there must be some way to save all the
> changes so user can have some record. It can save in any custom format
> as long as it is documented properly (so the lost of xml structure is
> not a real problem). Later, some one with time and skill may implement
> a helper program to ease the change incorporation.
This won't happen; we don't want the profile to ever be in a non-XML format.
> 2. Delete the editing function, but implement the reload function. The
> key is not to discard the old profile during the reload, so the
> program can compare the profiles to just update the changes; or refuse
> the reload if the change is too much and the program can't handle it
> and ask the user politely to restart the program.
Something like this will occur; you'll be able to reload the profiles
that you have already loaded and nALFS will attempt to preserve your
marks and run-status flags.
More information about the alfs-discuss