[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Kash Kontinued.
From:       "Michael J. Bedy" <mjbedy () mtu ! edu>
Date:       1999-10-30 4:27:03
[Download RAW message or body]


  I was going to get into this discussion when it started, but I was
really busy at the time. Anyway:

  This summer I put some serious consideration into a Kash type program.
IMHO it is the single biggest hole in the free/open-source movement.
GNUCash is ok, but is not great. It's good/bad points have already been
discussed. The reason that I did not start on it this summer is that the
KDE 2.0 API's were wildly changing at that point, and I knew that it
wouldn't be anywhere near done until after KDE 2.0 was out.

  So point one is that I think it would basically be insane to develop a
KDE 1.x version of Kash, because we'd just be wasting time. I wish that
the new KDE communication system could be documented (HINT!) so that we
could begin to consider what is necessary.

  The second point that I would like to make is that this may well be the
most important application the end user will have. What I mean is that the
information that this program will be trusted with may be the most
important information the user has. We should be concious of this probably
spend a little bit more time analyzing the design of the crucial portions
of the software than we might normally, before implementation begins.
(Portions such as the database, upgrade paths to new versions,
interactions between the GUI and the database, etc.)

  I think following good software engineering practices ( since I'm in a
software engineering class :-) ) would be a good idea here. Let's first
develop a set of features that we would like the application to have, and
make it fairly complete and also detailed. We can develop a number of
lists - features that are necessary, features that we would REALLY like to
have, features that we would kinda like to have, and features that may get
added to the application in the future. I think this planning for the
future is essential to producing a clean design that can be extended
without too much hacking.

  Once we have a list of features, we can get to work designing
everything. I don't think this is a project that would apply well to a
'hack it up' method of development. The more I thought about it this
summer, the more I realized that it was a much bigger undertaking than I
had thought at the start. 

  Another reason I would like to do more pre designing then perhaps is
normal is that I would like to see the effect of well maintained
documentation on a project. It is the habit of many (most?) open-source
development projects that the design docmentation is either incomplete, or
totally lacking, thus rasing the bar for anyone who might want to help.
We should commit to updating the documentation as the design changes,
although if we design well enough, the changes should be minimal.

  I think I will compose the beginnings of a web page dealing with the
features we want, including the features already posted to the list. I
will send the URL to the list when it is in place.

  What does everybody think? In short, I'm happy to contribute to a
project that fills this void in the Linux application field. If I can be
of assistance to you, Mr. Kahnt, in getting the project launched, then I
am glad to offer what little time I have to devote to such a project.


    - Mike Bedy

-----
Michael Bedy
Graduate Student
Department of Computer Science,
Michigan Technological University.

[prev in list] [next in list] [prev in thread] [next in thread]