[Leaf-devel] Webbased Configuration

[Eric Wolzak]

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

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

Re: [Leaf-devel] Webbased Configuration

[Eric Wolzak]

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

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