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

Reply via email to