Hello Charles, Lynn , list > > > Alternatively, use the same fields and write the > > > engine in shell.script or php using sh-httpd. or a > > > small server (boa, thttpd) > > > > It can be done with sh-httpd. Mosquito has used thttpd, > > but thttpd is considerably larger (and more versitile). > > My vote would be to use sh-httpd w/POST patch. >
> IMHO, any web-administration utility should be fairly web-server > neutral. Since sh-httpd is small, and presents what I believe is a > standard CGI interface to back-end programs, it is a good candidate. It > should be possible to use boa, thttpd, apache, or any other CGI-enabled > web-server with little difficulty, however. I agree with this. I like the sh-httpd, although I have some problems with persisiting /tmp files. The webconfiguration interface will not get lots of page views at one time, ( at least I hope so ;) ). But depending on what you are doing repeatedly viewing from one page. > > > Anyone who would like to volunteer to work on any ideas, code re-work > > within the existing Weblet, or developing the new code-base for > CLI/WWW > > configuration integration would be welcome to participate. > <snip> > > I am presently starting work on the framework. > > > > I believe that this is more of a devel topic, so I am moving the > thread > > to leaf-devel. Is anyone ready to work on and/or discuss any sections > > of this??? I would like to commit. ( time is also sparse :( ) I would propose to get something like webmin does. some routines for individual packages reading in variables combining them with package specific items and then into the engine throwing out a webpage /form after posting the option file is written out in standard option.textfile > I can commit to any updates/modifications to sh-httpd that may be > required. I think it's possible to dramatically increase the CGI > response of the existing sh-httpd when running CGI's, which would be a > big help for a CGI driven admin interface. That would be great. > I can also help with architure, debugging, and (hopefully) crafty > solutions to difficult scripting problems, but I can't commit to writing > a major chunk of code due to current time constraints (although this may > change suddenly if the company I work for suddenly "craters" :-/ ). I don't hope so ( for you and the company that is) > *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script > CGI's, would there be any benifit to wrapping the whole thing into a > unified structure? In other words, create a custom script-based CGI > interface, rather than trying to match "standard" CGI...something like a > shell-script version of PHP. It could probably be faster/smaller than > sticking with a conventional web-server/CGI approach, but would be less > portable to other web servers. Something to think about. that sounds good to me. fast and small is something we could need for the "doorstop" computers still running . > *WACKY IDEA #2* > I've been investigating forth, and will be working on a micro-controller > based hygrometer project running forth on an Ateml AVR processor in the > near future. I've been wanting access to a scripting language more > powerful than shell-script on LEAF, and I think forth might fit the > bill. It's possible to compile forth without *ANY* libc requirements, > but with the ability to talk *DIRECTLY* to the kernel (so you could load > libc and make calls to it, if you really wanted, and do pretty much > anything you want...remember the irreplacable part of libc is > essentially an interface between C programs and the kernel, the rest is > just a bunch of standard routines to make programmer's lives a bit > easier). That's a lot of power for an interpreter that would probably > weigh in at 10K to 20K Bytes, with code that can potentially run at near > optimized C speeds (ie *WAY* faster than shell-script)! sounds good, but sounds also like a lot of work I am not that kind of a coder. ;) > > I've wanted to code an initial bootstrap loader in forth for a while > (something that would boot from CD/Floppy/whatever, and optionally swap > out the kernel, allowing fancy boot-time configuration w/o having to > re-burn a CD to set kernel options. The ability to make kernel calls > from a script, w/o having any libc or /bin/sh dependencies is very cool > for a boot-loader. I also think an available forth interpreter could > potentially help the construction of a new packaging system as well as > fancy CGI admin scripts. > > I can volunteer time to help craft a forth implementation for LEAF, if > anyone else is interested... > > ...oh, if you really want to get wacky, the web-server could be written > in forth, too! > > ...signing off before I convince everyone I'm clinically insane! :-) > That would make two of us ;) Eric Wolzak ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
