RE: [Leaf-devel] Re: Webbased configuration

2002-09-01 Thread Richard Amerman

I must say your description of Fourth sounds great.  I have to agree with all your 
desires in a language for these purposes.
 
As to the Lego M's, though mine have been on the shelf for at least a year, you are 
always a kid if you choose to be!  Mine were a gift from my wife! :-)
 
I have played with the C like language on it, but not Fourth
 
Richard

-Original Message- 
From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]] 
Sent: Sat 8/31/2002 9:55 AM 
To: Nathan Angelacos; [EMAIL PROTECTED] 
Cc: 
Subject: 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

Re: [Leaf-devel] Re: Webbased configuration

2002-09-01 Thread guitarlynn

On Sunday 01 September 2002 09:58, Nathan Angelacos wrote:
 Hey Lynn, thanks for your comments.

 I guess we are approaching this from slightly different starting
 assumptions.  My assumption is that the webbased configuration engine
 is just a pretty face on lrcfg.

 The model I'm thinking of is you buy a linksys router, you plug it
 in to your LAN, look at the sticker on the router, and it says that
 if you point your web browser at 192.168.0.254, you'll get the
 configuration web page.  No passwords - you're in as admininstrator,
 configuring the router for first use. All it is doing is editing the
 equivalent of /etc/interfaces; /etc/network.conf or whatever, and
 then bringing up the interface.  Right?

 Similarly, we could say that the security of lrcfg is the strength of
 your root password for the internal interface, and whether you allow
 inbound telnet or ssh on your external interface.   Once the someone
 gets in as root, I really don't care if he abuses lrcfg - he already
 owns the box. :-)

I'm following you now that makes since and it would make it
necessary to bring up the default (index?) page as a login only
page (duh!). There may (or may not) be a defaut password to
enter the configuration menu via www. It would also be advisable
to run the server on something like port 81 so it would not be as
likely to be accidentally accessed in the first place. 


snip
I agree with the rest of what your saying... I was taking several 
steps further than you intended to in the application itself.

Thx for clarifying!
-- 

~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=sourceforge1refcode1=vs3390

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



[Leaf-devel] Re: Webbased configuration

2002-08-30 Thread Nathan Angelacos


Better sense tells me I should probably keep quiet, but ...

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...)

---

FWIW, my wish-list is something like this:

Must haves:
+small size
+URI (GET) or POST method variables exposed to the script language
+rfc-2388 mulipart/form-data compliance (must be able to upload a 
ipsec cert/crl via the web browser)
+inline scripting (like php)
+enough of a framework (.css / examples / docs) to make it easy for 
someone else to use
+master script (index.html?) that will take over the job of lrcfg 

Cool features, but not necessary
+logging
+http 1.1 compliance, especially keepalive
+cookie support
+std graphics building library (like fly or gd tools)

  
Not desired
+stand-alone server  
+high-performance 
+ssl 
+locked down security (need to be root to configure anyway!)

--

I'm sure others have a different wish-list. Charles' wacky ideas 
got me to thinking If you check out nullwebmail, its an 
executable that runs as a cgi under a web server - but any will do: 
thttpd, boa, mini_httpd (I don't know about sh-httpd).   Unlike most 
web-mail solutions, all you need is the single program - no 
complicated install process - just compile, put the program in the 
www directory and you have basic web-based mail.

Do you think that's a better way to attack this problem?  Rather than 
extend a web server, just build a really smart cgi?   I don't know 
the answer - just wondering if anyone else does.




---
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=sourceforge1refcode1=vs3390

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel