Lynn Avants wrote:
On Sunday 02 February 2003 08:11 pm, Matt Schalit wrote:
<snip>


   I)  central config-db
  II)  package system
 III)  gui admin program

That looks correct to me. A roadmap is absolutely necessary.

I would suggest letting people develop at will, at their own speed,
as has been the history of projects here, and let the better ideas
prevail.

I feel positively about a roadmap, but don't feel it's "absolutely necessary."
I *am* glad you and I concur on the three types of ideas being suggested,
and that from the discussions so far, the dependancies I listed
most likely exist if all ideas are well designed w/others in mind.

But as some people are already creating a modified weblet admin
package as I write this, I figure, let's not say that their project
should conform to the others.  It's really up to them to decide
how many rewrites are worth it as they see the other ideas proceed.


But then again, we are talking about standards here.
If we are going to say that the config-db is the only
thing that people should customize for their LEAF box,
then it's folly to start a weblet-admin program that
alters /etc/init.d scripts.

Yet if we say that the config-db is untouchable, and
that we need to use a groovy api to access it, then
it's folly to start a weblet-admin program that doesn't
use the api.  (Given an api, front-ends don't parse the db.
They use the api.)


So I'd like to see the config-db idea really
take shape.  I need to know what the format will be.

Will we take a poll on whether to have more standards?
(in addition to the current package format and libc standards)

Will we take a poll on each proposed standard?  That
could take a while....


I don't believe Perl is a feasible option on the LEAF box for CGI,
I don't think so either, but I thought I'd list it as someone
suggested it.


especially when Jscript and shell-script are and wouldn't require
an interpreter. Just for clarification, is Java being suggested instead
of Jscript? My reasoning is determined by the need for an interpreter.
Yes Java is being suggest by me. A remote Java app could run on a remote
computer that had a Java Virtual Machine (JRE) installed and connect to
LEAF via sshd using ssh and scp command api.  Nothing additional on the
LEAF box is required for this total-config Java app, only sshd.


Added options:
I integrated them into the post-config section.
Here it is again.


CONFIG-DB IDEAS
====================
     1.  flat-db
     2.  api-flat-db
     3.  api-xml-db
     4.  api-binary-db
     5.  template-api-xml-db



PACKAGE SYSTEM IDEAS
=========================
  [all are .tgz and FAT based ==> 8.3 filenames]

     1.  extend apkg to use one of the db ideas.
     2.  rewrite the package system from scratch to use one of the db ideas.
     3.  make packages automatically restart via trigger, when necessary
     4.  make remotely loadable packages via http, ftp, tftp, scp, etc.
     5.  make package system load all packages it finds, no more list.



PRE-CONFIG ADMIN IDEAS
===================================
  [all pre-config ideas utilize a master cdrom of utils/modules/packages/LEAF variants]
  [all post-config idea might use sshd on LEAF to facilitate scp and an ssh tunnel]

     1.  pre-config done on seperate OS using local Java app.
     2.  pre-config done on seperate OS using local Python app.
     3.  pre-config done on seperate OS using local Perl/www/cgi apps.
     4.  pre-config done on seperate OS via server based www/cgi apps.
     5.  pre-config done on LEAF box using Red-Hat dynamic hardware inspection app.
     6.  pre-config be upgrade capable (can clone a running LEAF)



POST-CONFIG ADMIN IDEAS
==========================
    1.  post-config on remote OS via LEAF based shell/weblet/cgi
    2.  post-config on remote OS via LEAF based perl/weblet/cgi
    3.  post-config on remote OS vua LEAF based javascript/weblet/cgi

    4.  post-config on remote OS via remote based perl/www/cgi
    5.  post-config on remote OS via remote based javascript/www/cgi
    6.  post-config on remote OS via remote based Java app.
    7.  post-config on remote OS via remote based Python app.

    8.  post-config on LEAF OS via LEAF based shell-script (like lrcfg)
    9.  post-config on LEAF OS via LEAF based vi/ae
   10.  post-config on LEAF OS via LEAF based dialog-gui-menu (like acfg -i)

   11.  Make pre-config and post-config into one project






Thank-you for putting this together Matt, I would imagine it can consolidate
some discussion.

np.  Where's Brad on all this, hmmm?
Matt




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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

Reply via email to