SEUL: seul-dev-admin

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

seul-dev-admin 

things this group creates: (in reverse order, most likely)
1. assorted administration software: both automated and manual.
  a. automated systems for things like log rotations, periodic security
     checks(?), etc.  these should also have appropriate front ends for
     communicating with the appropriate user/sysadmin.
  b. apps for manual low-level(ish) system tweaking: control-panel type apps,
     for telling the system about hardware changes, software
     installs/deinstalls, configuring time, etc, etc....
2. seul's master database, and an interface lib for it
   (someone think of a cool name for it, please)
  this is centralized database for keeping everything synchronized.  it will
  involve a lot of the stuff package managers do now, but be much more
  comprehensive.
   this db will be used by the admin apps in (1) to tell the system about
  anything they do (essentially to maintain state among all apps, between
  invocations, if you like to think of it that way) -- it will need an
  interface library so that other apps can use its services.


one significant example of the seul db being used:
  user installs a package/package-set/whatever - seul db notices and records
it.  the package installer, or the user through some control panel app or
something, tells the system to add apps from that package to a menu in the gui
for easy access.  this is done by asking seul db to do the task of adding the
menu item.  when the gui opens a menu (or just when it starts up, or realizes
it needs an update - if you're worried about efficiency), it queries seuldb
to find out what goes in that menu.  when the file disappears, the file
removal has to go through seuldb - therefore seuldb can remove it from the
menu's contents automagically.  next time the gui needs the menu, it checks
with the seuldb and finds out the correct new contents of the menu.


why the seuldb is cool:
(also some implementation points, for keeping it that way...)
  all requests within the scope we define for seuldb get shuffled through it.
therefore nothing will ever get out of sync (unless a coder screws up an
efficiency optimization and throws the db clients out of sync with the db --
but this would be a bug; make sure it doesn't happen).  in the case of the
example above, the effect is that the menus are always synchronized with what's
actually on the system.  (not like the way they usually are now, i may note.)
  seuldb is more expansive than a current package manager - it will deal with
multiple package formats and make some (semi-successful) attempt to arbitrate
if the user installs something bizarre.  the interface will also encompass
plug-in replacements for utilities like tar and install, which are trivial
to implement with the db written correctly, since it will just involve adding
a call to seuldb_register(), or whatever, when the utility installs stuff.
pretty simple, and pretty useful -- provided the seuldb lib is done right!
  seuldb will be abstracted from other apps through the seuldb lib, so they
do not need to know how it does stuff, just that it works.  internally, lots
of cool stuff can be done, and different schemes can be tested easily while
this is in development.


more on implementation:
  this is some stuff on internals: if you're not coding the guts of the
seul db engine, you do not know this (at least, in the sense that your seuldb
clients should not rely on any of this).
  the package manager/db implementation: there are package managers out there!
use one!  i've been looking into package managers and and distribs and am not
ready to commit to one to base seul on yet, though -- both redhat and debian
have distinct advantages and limitations.  try to write code somewhat
independently of package manager for this reason (centralize pkgr-dependent
code, etc).  i will suggest that we do the first implentation with rpm, though,
since it is currently the most well-documented and generally easily usable
pkg mgr out there: but this is open for debate within the admin group.
  furthermore - we will need the ability to extend the pkg managers abilities.
two things to look into here:
  1. hacking the package database for whatever manager is being used.
  2. augmenting it with a secondary database.
  (3. (sidenote) don't forget about unix config file weirdness)
(1) will depend greatly in feasibility on the package manager used, but it
may be appropriate for efficiency and reasons, and if done well can make the
code more easy to maintain (if done badly, it can make it impossible to
maintain, too).  (2) is probably the most appropriate approach to take right
now, since it is the most portable as we try out different stuff.  i would
suggest looking into mysql (like msql, but different), to use for the secondary
db driver.
and what (3) is referring to is the fact the seuldb will get the fun and
nasty job of dealing directly with the config files (.rc's and everything else,
in all their incarnations), to make things happen.  this is where things
will get nastiest as far as making things work right, because the user can't
touch a package db without going through the packager interface (for example),
but will be naturally tempted to or accustomed to or need to modify config
files by hand.  i have some ideas on how to get this to Do the Right Thing,
but that is something to go into later, in much more detail.


suggested development plan for installer:
1. research packagers, db's, other stuff.
2. develop a spec for the seul db interface, coding enough to make it barely
   functional as a package manager, and do sensible debugging output (for
   development purposes).
3. continue coding the seuldb internals, and start on the admin ("control
   panel") apps.
4. continue with the seuldb internals, and really dedicate effort to the
   admin apps once the gui spec is available from the ui group.

that's all for the seul-dev-admin general layout.  there's a lot of stuff here,
and it's bound to have problems, so criticize anything here if you know of
a better way to do it.  do not start picking on small internal details yet
though, unless you think you've found something implied by this general spec
that will end up really messing things up at a lower level.

-luka
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------