Greg Morgan wrote:
Matt Schalit wrote:
> > o All the types of variables used in all LEAF distros must be
collected
> > and given a type name.
>
>
My presupposition is that the LEAF lrp archive is a great tool. It is
great for what it does. Its that just that the gziped tar archive is
not easy to edit by hand. In any system that evolves from these
discussions, the system has to have an implementation plan. I don't
believe this is complex at all. Where does a project like this start? I
think you have to go and survey all the files and variables that a CGI
GUI or other more user friendly system would display for the user to
edit. How would any program know where to find these variables to edit,
if you didn't know what package they were in or even which file that
they are in? How will you know what priority a package will be on an
implementation plan, if you cannot survey its importance in the larger
scheme of all packages?
The template system I started to describe here is executed externally
from the LEAF image. It does not use the LEAF footprint to work in. The
result of running a modified Anaconda installer it to spit out LEAF
images. The XML is not stored with the working LEAF Image. If the
resulting GUI system is not mature enough to support all desired
edits,then the floppy image can still be hand edited where support is
lacking in the GUI.
http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg06097.html
> So I think there are two camps evolving in this discussion.
�Three sir�. Two camps trying to edit all this information via a web
GUI, and the third camp is my proposal. The third camp is a system
using Python programming that is hosted on a full featured platform
using templates. The Python GUI would allow a person to develop more
full featured GUIs, if is not running on the target LEAF platform. This
still presumes we are taking about say a 16meg host. In a way the third
camp could be likened to a cross compiler.
Ok I'm onboard now. I didn't realize the scope of your idea,
which covers two of three idea types I've gleaned from these
discussions, namely:
I) config-db
III) gui-admin
You have not described anything as far as I can tell along
the lines of a new packaging system, idea number II I listed
in another post.
Unless you can correct me on that, I'm not sure that
your idea could be easily realized if a new packaging
system comes out.
> What is the goal here?
I thought there were three:
I) config-db
II) package system
III) gui-admin
Somehow we want to let users have a GUI to edit their LEAF systems.
Agreed, that's one of the goals.
At the very heart of this system is editing a variable.
[snip]
Here you go on to describe the reasoning for a type field,
and I agree now that it's an excellent idea. I abhor the
look of the xml file, but as you suggested, it has little
bearing on the legitimacy of the essential fields to make
life much easier to program for.
o How could the target file be modified to make inserting the list of
variables from a database?
o Either define a region for all variables to be dumped between in
the files that require editing. The LEAF distribution configuration
files would be modified to have this kind of target in them as an example.
# BEGIN GUI CONFIGURATION VARS
# END GUI CONFIGURATION VARS
I don't see that working, as people define variables along the
way, not always at the top. I was guilty of that for a long time.
o or dump them into a file that is destroyed each time the GUI
modifies the values. This would be a simple approach from a programming
prospective. This is much like the /etc/host file is built from the
network.conf file. The file would be sourced by a shell script. It may
be easier to have several of these sourcable files created instead of
one giant file.
I don't understand this one. You start by asking how the target
file should be modified for inserting the list of variables,
and you answer that by not describing how to modify the target
file but rather how to "dump them into a file that is destroyed...."
In this case, the target file would have to source the destroyable
file at the right time == a gamble for the same reason as the before,
people define important variables throughout their shell scripts.
o or have a template of how you want the sourced file to look. This
file would be edited and put in place to be sourced after it is edited
by the GUI.
This makes the most sense.
o If this GUI editing system is to be reused across all LEAF
distributions, how would these distributions have to change in order to
reuse the code?
o Use variables in lrp.conf.
o Use case statements in shared packages that draw on the variables
found in lrp.conf.
o These variables in lrp.conf may or may not be in the configuration
system. For example bering only uses the Shorewall firewall. This
would variable would not be edited by the GUI editing system.
I vote for no backwards compatability. The changes are too radical.
Upgrade to a new LEAF version designed to support these 3 ideas.
o Would you use XML on the LEAF distribution, if the GUI editing was
placed on the firewall disk? Probably not because of space consumption
on floppy disk images.
Sounds reasonable enough, I guess an xml-db would get long.
But have you tried to compress one for grins? Are we demanding
that this fits one a floppy? Why not move to CF? Any ide connector
can handle it? I thought we solved the write-protect issue.
o Would you use XML on a cross compile type system? Probably because
the XML file could be viewed and edited by hand. The XML �database�
would _not_ reside on the LEAF disk. You would miss the point of my
posts if you did not understand that I proposed modifying a system like
Red Hat's Anaconda installer to use XML. The saved state of a
configured system would be stored in one resulting XML files. Other
supporting XML files would provide direction to create the
configuration. The modified Anaconda GUI installer would create usable
diskettes. The usable diskettes could still be hand edited, if required.
Makes sense. It's a reasonable choice, xml, but isn't it
Microsoft's format, which I don't consider to be worthwhile
edit by hand?
>> comment on the deficiencies of a flat-db
5.) Yes it is sourcable. It has to be so that bash scripts can use the
variable.
It's nice to have it sourceable if a config-db is kept
on the LEAF box, but it doesn't have to be if there's
an api that reads it and sets the environment variables.
6.) Yes I would agree that �using sourcable straight text config files
are a good system�.
7.) I don't believe you have given us enough �glue� to get to the place
that this sample represents.
Yes it has failings. You have described much better improvements.
But is xml inheriantly more capable of organinzing the same fields,
given a flat-file example that included all the same fields?
I'm just trying to get to something I can read/skim. I can't
do that easily with XML because there are too many special characters
and it's not very columnal.
Whatever �policy� is used to implement a GUI editing system, I believe I
have at least described some of the �mechanisms� behind the �pig with
lipstick� i.e. GUI. Hopefully, these thoughts will help chart a course
for a GUI front end.
Regards,
Greg Morgan
Excellent description and reasoning. Any reason for Python?
Would you consider using Java?
Regards,
Matthew
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
