Weekend thoughts

[Doug Loss <dloss@csrlink.net>]

Since the volume of mail on this list has slackened in the past few
days, I had some time to think about what we've been discussing here. 
Here are my thoughts on a couple of things.  They're probably worth
exactly what you've paid to read them, so take that into consideration.

It appears that those of us who have actual code in development aren't
ready at this time to open it for outside development.  This is entirely
fine and appropriate; folks, if you're developing anything based on what
we're discussing here please let us know how you're progressing and if
anything we're proposing or planning will cause difficulties with what
you're doing.

There is a question of what those of us who don't currently have code in
development, or who don't feel capable of coding, should do.  I think
it's important that we start getting something concrete developed, as
having a base to work from tends to distill the discussion from vague
philosophical thoughts to more precise ideas intended to further
development.

I was reading a piece on slashdot last night about the GNUstep API (I
use WindowMaker, so this was of particular interest).  Some of the
comments mentioned that it was now a three-way field for desktop
environments between GNOME, KDE, and GNUstep.  Since just last week it
seemed that GNOME was a pretty clear choice for the presentation layer
of whatever we do, this seemed like a very abrupt change.

This got me to thinking that perhaps our joint efforts should be
initially directed towards developing the "back end" engines that
collect, process, and store the data rather than towards the user
interfaces to those engines.  That way, someone running KDE could
collect and input the data, which could then be used by someone else
running GNOME or GNUstep to compile progress reports, etc.  If we do
this properly we could include clients for all environments in our
package as they get developed, and those clients could be fairly easily
done by one or two people working on whatever they found most
interesting.

This probably applies to Micah's edulp program too, although I'm a bit
hazy on that.  It may be that this is the kind of program that I'm
calling a client in the paragraph above, and that will need to be
developed separately for each environment.  Assuming that to be true, we
should probably follow Micah's progress on it and develop equivalent
programs for the environments we (as individuals) are most interested
in.

Finally, here's something I posted to seul-dev-install back in August. 
It's a website for an installer program that presents users with a
graphic interface to a "configure, make, make install" installation of
software.  Something like this may be a consideration rather than RPMs,
DEBs, etc. if we're looking at getting our software installed on
LinuxPPC, MkLinux, and various other non-x86 ports in addition to the
standard x86 distros.  Here's the URL:

<http://www.gv.kotnet.org/~kdf/installfest/>

-- 
Doug Loss                 It is impossible to imagine Goethe
Data Network Coordinator  or Beethoven being good at billiards
Bloomsburg University     or golf.
dloss@bloomu.edu                H. L. Mencken