I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF.
I just finished seeing monowall and the screenshots are great. It is just what I had in mind and Eric Wolzak has asked for ideas too. The monowall interface encapsulates most requirements. It may do good to invite Michael - the monowall author to participate here. Apart from what has been listed below, the GUI must have a webmin like definition to allow authors to write new package screens easily and confirm to a standard. If this is done, then changing themes will change the look and feel across all packages. We also need to look at SSL support if web based administration is contemplated. Mohan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Schalit Sent: Tuesday, February 18, 2003 12:10 AM To: [EMAIL PROTECTED] Subject: [leaf-user] Update: Short term LEAF project goals This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. LEAF is a loose collection of kind people who share a common interest in embedded Linux. There's no top-down organization here, per se, but rather the following ideas are what people are most excited about and working on. They are listed in an order that likely denotes their place in our unoffical roadmap. The point here being that it'd be tough to build a GUI admin system when you know there's a new package system coming out shortly: 1) Central configuration database 2) Central package repository 3) New package system 4) GUI preconfig 5) GUI admin Central Configuartion Database ================================ This is a way of storing the variables and values that make your LEAF box unique, like your IP addresses, in one single location and making a new command, perhaps leaf-cdb, that is used to access the db. Values like IP, netmask,and hostname that are common across packages will be listed once. No more entering the same data 5 times across 5 packages! The current idea is to use a stucture similar to the linux /proc set of subdirectories. Another idea is to burp that structure out of an xml database, perhaps stored remotely. Simplicity is a main goal of this project, a goal that contrasts with XML to some extent, but XML may be essential for GUI admin. Central Package Repository =========================== No more looking all over our website for packages. All of them will now be stored in a single repository. Probably still fat16 with 8.3 filenames. Not sure. New Package System ================== A new package system would use the new central-db to get it's values from. We are interested in making the packages a LOT smarter and making it possible to load them from remote locations. A smart package contains a manifest of all it's variables and all possible values, offering that information to and incorporating those into the central-db. The run-time files that each package uses, the ones we customize nowadays like /etc/dnscache/env/IP, will be generated at boot time in the future, similarly to the way the /etc/rc?.d directories are generated on the fly now. This packaging system will require each package to provide a template of it's dynamic files. Templates are like mad-libs. You get the values out of the db, and once you fill them in, it's funny. GUI Pre-rollout Config ====================== We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing. This is very dependant on new packages and a new central-db. GUI Admin =========== Everyone likes how weblet can show us information, but can we use it to administer our LEAF boxes? A lot of people would like to do something like that. But weblet/cgi requires a lot of shell scripts on the LEAF box. Plus there are security and space concerns. We are far away from settling anything on this or choosing the best app to use, but I have suggested a Java app rather than a weblet based approach. Python has also been suggested. Now the more capable one makes the GUI, the more it increases exponentially in complexity to build and use. We'll have to make sacrifices and assumptions about how easy this should be for users. Some tough decisions! But, if we used XML as the foundation of our central-db, then a Java or Python app could query that XML and generate the admin pages on the fly. No more changing the GUI because ntpdate added another variable. The GUI would just be written to create the fields and field-value options that the XML database told it to, on the fly. If the ntpdate package starts with a properly written manifest, everything else is automatic! That deserves a tiny w00t w00t. okey naw, matthew ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
