Re: [Leaf-devel] Re: Webbased configuration
> Better sense tells me I should probably keep quiet, but ... Nah...speak up. We won't even flame you here! > Back when this discussion came up previously (Dec 2001/Jan 2002?) I > was able to get micro_httpd working with an embedded lua interpreter. > It allows one to write html code with inline lua scripting, like php. > To add some real numbers to this dicussion: > > micro_httpd - dynamically linked against libc9404 bytes > lua_micro_httpd dynamic libc, static lualib 75972 bytes > > Compressing with upx gets it to 39K, which is still big for a > diskette-based configuration engine. If FORTH can really get us an > embedded language in 10K, that sounds great. I'll check the site > Charles mentioned tomorrow; any other pointers anyone can give - > please share! (I'm not a coder - but don't mind getting my fingers > burned either...) I like LUA (haven't programmed anything real in it, but I've gone over the docs pretty well, and compiled the stand-alone LUA interpreter). I think it's excellent at its targeted application (a scripting language for complex programs), but is not particularly well suited to being added to the core of a LEAF distribution for a few reasons: Size - While fairly small for a scripting language (vs perl, python, etc), LUA is still pretty large. Requires libc - Not a show-stopper...almost all parts of LEAF require libc, but I'd like to have a light-weight scripting language that could boot w/o libc to enable some potentially complex booting scenarios that have been discussed previously, like run-time selection of libc version, mixed libc environments (ie a base system running off ulibc, with optional add-ons using gnu libc), and similar. We already have sh - While more powerful than ash in several respects (especially with handling numbers), I don't think LUA provides dramatically more functionality than is available with standard shell-scripts...especially if a light-weight numeric processing tool was provided to extend ash's native abilities in this regard. Untyped - I especially don't like the fact that LUA is untyped (strong integer & floating point math capability is one of the key things I miss when programming in shell-script). I may be missing something with LUA since I don't have much experience with it, but as an example, I'd like to know how well a numeric processing program (like rrdtool or MRTG) would code in LUA. This is one of the things I'd like to code in a small script for LEAF, but have not attempted due to the limited numeric processing available in sh. LUA is definately better with math than sh, I just don't think it goes far enough. No linux syscalls - There is no inherent capabilitiy to directly make linux syscalls, and given LUA's untyped data structures, grafting on this ability would likely be difficult. With the ability to directly make linux syscalls, not only is the requirement for libc drastically reduced (or eliminated), but ti becomes possible to script things like a full-fledged web-server, e-mail sending program, or other network based program, and it also becomes possible to script core utilities (like su, chroot, etc) if desired. Forth: Tiny - about 1/4 the size of LUA No libc required - works on any system, even at bootstrap with an initrd in the 10's of K, rather than 500K+ low-level-power - While still considered a scripting language, Forth has the ability (and was initially designed) to do low-level machine controllike "c", you get the ability to talk directly to the machine...unlike "c", you have small programs, no compile required, and no libc required (at the expense of somewhat slower execution and coding your own library routines). Talking directly to the machine means you can execute linux syscalls, load/call external libraries (including libc) if required, and pretty much do anything possible in a "real" compiled programming language. For math, you get everything from bit-level twiddling to whatever you want to write for a math library (single/double precision floating point, arbitrary precision calculations, whatever)...of course for standard things like floating point, there are off-the-shelf GPL/public-domain "libraries" (actually, word-sets in forth) availble from a variety of places. Drawbacks - Forth is considered by many to be a wierd, arcane, and obscure language. Of course, I don't think LUA is going to be replacing C or Java anytime soon, either, and I actually consider LEAF a bit obscure, although probably not wierd or arcane :) There is actually a pretty large group of folks continuing to write Forth (and commercial vendors providing supported toolchains), but it's all in the "hidden" world of micro-controllers...the tiny CPU's controlling your dishwasher, oscilloscope, etc...several folks are even running forth on their Lego MindStorms RCX controllers (why didn't they have these when I was a kid!?!). Drop by comp.lang.forth sometime, and you'll see a pretty active user community.
[Leaf-devel] Webbased Configuration
Hello all, I agree with Erich that it would be wise to get an architecture before thinking about the implementation. IMHO it should be : -easy to configure. -flexible , so adding new packages is possible without much programming. -flexible 2- so it is possible to use the same system on oxygen, bering ,dachstein, Wisp by merely changeing the Tools configuration file. -useable also on "slow" systems. I thought about it sometime and came up with a kind of a flowchart ( I am afraid , I am not good at Ascii art, so I put it up my webserver: http://wolzak.de/leaf/config1.jpg After some looking at this graphic I noticed that 1. The cgi and the primary Part have a common Trunk Useing a template with the variables to create a html or config file. 2. The intelligenz of this programm is on the firewall. With each call , there is a lot of computeing. 3. The configuration Template is created dynamically, but doesn't change . So why not create it "offline" or better of the box. So I came up with the next Idea: http://wolzak.de/leaf/config2.jpg The first Action is created on whatever computer under whatever system to create the "Parsing rules" The HTML Template and the Config Template. The Idea behind this is that as soon as the external Parser is written, it can create any HTML.template , parsing rules or config template just by creating a modules or package config file. What is this parsing rule thing. This is a file build something like `grep -q ^noauth` && var1=noauth var2=$NETWORK_INTERFACE var3=`ls /etc/` now after running this shell script or any other (Forth, Java alike) you would have the variables var1, var2, var3 set Those are combined with the HTML template just by catting the template with the variables at the appropriate place. What kind of place is told by the Module configuration file. The kind of field the vars are placed in is destined by the kind of data it expect ( options, filenames, freetext etc) The Modules Config file (which could also be a database can be different formats: 1. xml in that case the template, parsing rules and config template can be generated by merely applying a xsl stylesheet. 2. something with different fields example: field 1 = 0 (optional) /1 demanded field 2 = 0 (single) /1 (repeatedly possible) field 3= variable looks like 1 NAME=value 2 NAME value 3 value 4 filename 5 name= (value1 or value2 or value3) 6 name (value1 or value 2 or value3) 7 ( value1 or value2 or value 3) 8 ... 3 Database. I think I prefer the first option (xml). ... Any Comments , Reactions, flames Eric Wolzak member of the Bering Crew. --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Webbased Configuration
> So I came up with the next Idea: > http://wolzak.de/leaf/config2.jpg I like this better. Another thing I'd like to see in all architecture discussions of a configuration system is alternate display front/back ends. I'd like to see a simple text menu type system that could extend and replace lrcfg, not just web-only configuration. This would require a configuration engine with a standard interface, which is pretty much what you've got drawn in config2: "Writing Webpage" - The output of the "parsing" block can be processed and turned into a text screen, html page, text-to-voice translator for a telephone interface, or whatever someone decides they want to code :-) Conversely, in the "Writing Config File" branch, the input to the "combine layout with vars" block should easily be able to come from something other than a CGI script. As long as the interface is simple and consistent, presenting the information to the user in the form of HTML, full-screen text menus, line-based interface (aka brain-dead serial terminal), or whatever (and linking the users response back to the configuration sub-system) should be fairly straight-forward. Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Webbased Configuration
On Saturday 31 August 2002 14:21, Eric Wolzak wrote: > Hello all, > > I agree with Erich that it would be wise to get an architecture > before thinking about the implementation. > IMHO it should be : > -easy to configure. > -flexible , so adding new packages is possible without much > programming. > -flexible 2- so it is possible to use the same system on oxygen, > bering ,dachstein, Wisp by merely changeing the Tools configuration > file. > -useable also on "slow" systems. Agreed, in all likely regards, we are integrating/replacing lrcfg with this project. A good idea would be to consider 'apkg' as well, since it includes some advanced features that are lacking with 'lrcfg'. Considering (and examining) Forth, this will possibly end up in a totally new base system that may or may not be integrated with existing variants and should be considered. A new boot-method and required packaging/configuration compatibility are my reasoning behind this statement. This project will end up with a required baseline for compatibility. In examination of possible Forth implementations, eForth and kForth (18K download) seemed good possibilities. The User's guide for kForth seems pretty easy to interpret. http://ccreweb.org/software/kforth/kforth0.html > The Idea behind this is that as soon as the external Parser is > written, it can create any HTML.template , parsing rules or config > template just by creating a modules or package config file. Thanks for making the flow-charts! The second jpeg is pretty much what I have had in mind. I don't see a distint reason for using uncgi, particularly with POST data, many people on the list also have ~10 line GET parsers as well. Personally, I see a more secure method by using the CGI to simply "set the environment" and call the applicable "executable" to do the actual work, so ineffect the CGI/www-server is the parser and doesn't do the work. The "executable", run under a SUID, can be done in any language that can be interpreted. Does anyone see any problems with this method? > The Modules Config file (which could also be a database can be > different formats: > 1. xml in that case the template, parsing rules and config template > can be generated by merely applying a xsl stylesheet. > I think I prefer the first option (xml). I would prefer this method as well. I have only one question, will the XML need an interpreter on the www-server? Thoughts??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Webbased Configuration
Hello Lynn, Charles , List > On Saturday 31 August 2002 14:21, Eric Wolzak wrote: > > Hello all, > > > > I agree with Erich that it would be wise to get an architecture > > before thinking about the implementation. > > IMHO it should be : > > -easy to configure. > > -flexible , so adding new packages is possible without much > > programming. > > -flexible 2- so it is possible to use the same system on oxygen, > > bering ,dachstein, Wisp by merely changeing the Tools configuration > > file. > > -useable also on "slow" systems. > > Agreed, in all likely regards, we are integrating/replacing lrcfg with > this project. A good idea would be to consider 'apkg' as well, since > it includes some advanced features that are lacking with 'lrcfg'. > > Considering (and examining) Forth, this will possibly end up in a > totally new base system that may or may not be integrated with > existing variants and should be considered. A new boot-method > and required packaging/configuration compatibility are my reasoning > behind this statement. This project will end up with a required baseline > for compatibility. > > In examination of possible Forth implementations, eForth and kForth > (18K download) seemed good possibilities. The User's guide for > kForth seems pretty easy to interpret. > > http://ccreweb.org/software/kforth/kforth0.html > > > > The Idea behind this is that as soon as the external Parser is > > written, it can create any HTML.template , parsing rules or config > > template just by creating a modules or package config file. > > Thanks for making the flow-charts! > The second jpeg is pretty much what I have had in mind. > I don't see a distint reason for using uncgi, particularly with > POST data, many people on the list also have ~10 line GET > parsers as well. Personally, I see a more secure method by > using the CGI to simply "set the environment" and call the > applicable "executable" to do the actual work, so ineffect > the CGI/www-server is the parser and doesn't do the work. > The "executable", run under a SUID, can be done in any > language that can be interpreted. Does anyone see any > problems with this method? > I agree with you I didn't mean the Programm uncgi but rather some engine creating variables from the cgi statement. > > > The Modules Config file (which could also be a database can be > > different formats: > > 1. xml in that case the template, parsing rules and config template > > can be generated by merely applying a xsl stylesheet. > > > I think I prefer the first option (xml). > > I would prefer this method as well. I have only one question, > will the XML need an interpreter on the www-server? No it is not even available on the router as the xml files are only used to generate the "parsing rules", "html template" and "config template". I just have to be more precise with describeing ; ) ( > > Thoughts??? > -- > > ~Lynn Avants > aka Guitarlynn Reactions ? Eric Wolzak --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
