On Monday 03 February 2003 02:41 pm, Matt Schalit wrote: > I would suggest letting people develop at will, at their own speed, > as has been the history of projects here, and let the better ideas > prevail. > > I feel positively about a roadmap, but don't feel it's "absolutely > necessary." I *am* glad you and I concur on the three types of ideas being > suggested, and that from the discussions so far, the dependancies I listed > most likely exist if all ideas are well designed w/others in mind.
I definately can't disagree with this, other than sometimes the 'better' idea(s) don't prevail for a variety of reasons. No one will use a program that doesn't exist and this isn't along any further because no roadmap AND code was really ever presented. I am sure one of the main reasons Eric W. presented some code was so _something_ was there to start with. I really don't think he wants to re-write any code more than once or twice. > But as some people are already creating a modified weblet admin > package as I write this, I figure, let's not say that their project > should conform to the others. It's really up to them to decide > how many rewrites are worth it as they see the other ideas proceed. I agree, but I would like to see if several of us can agree on a roadmap to follow and break up some of the work. I don't write Java or Jscript, but I can write some functional sh. I prefer to let someone else code where I am deficient and bring the pieces together. I feel this could be done within a month or so with several developers working in pieces that would actually work together. > But then again, we are talking about standards here. > If we are going to say that the config-db is the only > thing that people should customize for their LEAF box, > then it's folly to start a weblet-admin program that > alters /etc/init.d scripts. > > Yet if we say that the config-db is untouchable, and > that we need to use a groovy api to access it, then > it's folly to start a weblet-admin program that doesn't > use the api. (Given an api, front-ends don't parse the db. > They use the api.) I think it will be as it always has been. People will use what they want. If they don't create a more popular or useful system, it eventually dies due to lack of use/development. It either gets used and/or extended or doesn't. Standards are simply what keeps getting used. The biggest problem IMHO with a flat-db would be the ability to hand-edit the file(s). If no comments or description fields are used it will require a user to locate the variable(s) in the package conf file(s), then edit them in the 'db' file. I think it is a fair trade-off. If an easier configuration method is available (or choice), then you ought to be smart enough to figure out what variables to change if hand-editing. There are atleast 3 people I know of that maintain many Dachstein routers and have already gone to a similar approach..... I think the idea is proven. All it needs to move between different variants is compatibility to the core configuration files and packages. > So I'd like to see the config-db idea really > take shape. I need to know what the format will be. One of these??? name = value name value name:value name.value name = value #descript > Will we take a poll on whether to have more standards? > (in addition to the current package format and libc standards) > > Will we take a poll on each proposed standard? That > could take a while.... Other than a db format, it really doesn't matter. The libc thing is a matter of which binary tree(s) to use when generating an image. A flat-db can have many columns as desired, you can parse with sed, cut, and other shell-util's by columns/delimiters. Let's use passwd and shadow as a good example. I really don't think Matt and Greg are too far off from each other in the 'preconfig' department. Let's say a XML or Java applet takes the initial configurations for the system (and/or packages). Let's say this configuration is saved to a 'db' text file on a floppy. The user inserts the global CD-ROM which boots and generates a floppy or IDE image from reading the 'db' file on the floppy. Granted this global CD would need to have the capabilities of writing an IDE/CD image or atleast moving it on a harddrive partition, but that is feasible on 650Megs. Considering use of RH-s autodetection to the preconfig, it won't work _unless_ you run it on the LEAF box . > > I don't believe Perl is a feasible option on the LEAF box for CGI, > > I don't think so either, but I thought I'd list it as someone > suggested it. ;-) > > especially when Jscript and shell-script are and wouldn't require > > an interpreter. Just for clarification, is Java being suggested instead > > of Jscript? My reasoning is determined by the need for an interpreter. > > Yes Java is being suggest by me. A remote Java app could run on a remote > computer that had a Java Virtual Machine (JRE) installed and connect to > LEAF via sshd using ssh and scp command api. Nothing additional on the > LEAF box is required for this total-config Java app, only sshd. Or saving to a floppy. The 'db' file(s) are quite portable (by config.lrp????) > > Added options: > > I integrated them into the post-config section. > Here it is again. TY, I think it is pretty accurate now. Thanks > np. Where's Brad on all this, hmmm? Good question, or Eric? -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net ------------------------------------------------------- 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
