Knoware final status

[Brian Beck]

Well, after some SVN account issues, Knoware is finally committed (at
about midnight last night, during much freaking out).  Note to self:
"next time" develop in SVN for the whole development process.  Sheesh!
 That said, here's where Knoware currently stands:

CLIENT
* The client is currently minimal but should fulfill user
expectations.  In fact, the server supports a few 'client' operations
that the client currently can't even perform (this is because it's
easier to add new features to the server than to the client). 
However, the most important aspects such as problem browsing, problem
submission, and system scanning seem to work okay.  My proposal does
mention that the client I expected to have complete at this point
would be minimal.

* One part that is a bit shaky is the network code.  This was the
result of most parts of Knoware not needing a persistent connection,
such as viewing problem and system information, but the discussion
aspect (since I promised "live" chat) requiring a persistent
connection.  After experimenting with a persistent Twisted TCP server
and XML-RPC, I settled on plain old HTTP.  This means that the
discussion actually depends on polling for new messages instead of
being truly live.  I should have thought more about such protocol
issues from the beginning.  The result is that I was switching out
socket and RPC code close to the end of development, and some network
operations may not work.  Easily fixed, just requires some
refactoring.

* I never did find a program that lists installed libraries with
versions on a user's system, and creating my own would have been out
of the scope of this project.  So only hardware information is
gathered currently, and this is done through lshw.  I switched back to
lshw in the end due to parsing problems, but I don't expect this to be
a problem in the future -- I hope to create a scripting interface such
that as long as the client or server knows how to parse the input, any
hardware detection scheme will work fine.  So I had to sacrifice
hwinfo's more extensive output for lshw's
only-really-extensive-as-root output.  Keep in mind, non-root output
from lshw is still fine for solving problems!  On the upside, driver
information is included in the hardware output, which is just as
important as library information, I think.

SERVER
There are three main pieces to the server.  They are all fully
functional, for what is expected at this release at least.  There are
a lot of Python module dependencies, which will be mostly enumerated
below.

* The web server. As I said, client-server communication happens over
plain old HTTP.  I used CherryPy for this, with Cheetah for HTML & XML
templating.  This allows me to add new features /fast/.  As I said
before, unfortunately this limits the discussion aspect of the
client-server model.  This area might be refactored in a later release
if necessary.

* The database layer.  I used SQLObject with SQLite as it allows for
quick development and I am very familiar with it.  Not much to say
here, it's relatively simple.  One thing to note is that while the
server and database happily support multiple systems per user, the
client has no way of taking advantage of this, since there is no
method for system management.  The client will always just see the
system it is being run on.  I would have had to change a bunch of GUI
decisions very close to the end of development to accomodate this, so
at that point I didn't want to mess up what I'd already done.

* The statistics portion.  I nearly fell out of my seat when I found
out a couple weeks before the deadline that nobody can actualy get
Orange working on Linux.  So I had to go back to the way I had given
up on, which was interfacing with R.  I then realized that in
practice, the RPy module is not fun to use due to name mangling and
such.  I ended up just making Python scripts that write R scripts and
R input tables.  Actually, I'm glad I did it this way, because it was
easy in the end.  The R output does give meaningful statistical data
with enough input!  You'd think that you would make an input file for
each problem you are trying to solve.  The cool part is that no matter
which problem you are looking to solve, they all use one input file,
then you just tell R which problem is the dependent variable.  This
allows it to not only find which system components are valuable
predictors, but if one problem is a predictor of another.  Very
useful.  I will send another e-mail later with sample output,
including some graphs.  Output is not currently pretty, just some
numbers.  This can be taken care of with some simple templating.

And that's it!  I will be running the server on my machine (it is
hard-coded in the client for now) so that people can test out the
client.  Hopefully you can get it to run without problems.

I intend to send another message to this list with my KDE development
experience side of things, how I could have improved my project
schedule, and such.

-- 
Brian Beck
Adventurer of the First Order