> > 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. > 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 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. 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" :-/ ). *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. *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)! 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! :-) Charles Steinkuehler [EMAIL PROTECTED] ------------------------------------------------------- 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
