From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-07 14:42:28
> Well, what you propose is what I've got now, sans the File class
> (easy to add, though). So if you want to do it for your own experience,
great;
> but otherwise it would be a duplication of effort. Here's a very old UML
> drawing of my early ideas:
>
> http://home.stny.rr.com/webconnections/linuxeeg.gif
Hay looks good! No I don't want to reinvent the wheel. :-)
BUT I would like to move things around a little to allow for future
expansion/changes.
I'm working on the UML now so should be up either tonight or tomorrow!
> I have been doing more design work on whiteboard and paper than
> using the UML software, but when I finish up, I'll diagram what I have
like I
> did above for the group, because it gives a nice conceptual view of the
> classes. As I said before, it comes out close to what has been discussed
here, except for the
> Sensor class. Methinks I overlooked the obvious in my early OO designs by
> focusing on the data stream as an object instead of the sensor itself.
I'll get the UML I've got out quick and see what you think. It's in no way
as detailed as yours but it breaks things up a bit more so that blocks can
be changed latter without rewriting the whole thing.
Anyway when you get it take a look over it and tell me what you think!
> I also echo Andreas' sentiment that what we need is a document
> that organizes the decisions which have been made to date, including
current
> design ideas, feature needs that we have identified, areas that we know
are
> missing (such as biofeedback practitioner's input), and so on.
Hear HEAR..........I AGREE whole heartedly.
If we have it captured somewhere we can access when/if we need it. :-)
> This would mean digging through scores of message threads to mine the
information,
> and fold them into a document.
> John--you had started one which touched on some of these aspects in
> your Requirement Specification document. I think we need to continue with
work
> on that, but rigorously add content based on all the voices from
> this list.
YES I agree I had planned on doing this BUT got side tracked by LIFE!!! :-(
> However, your document was in MS Word format. A think a better
> solution would be something that is a little bit more portable. The first
thing
> that comes to mind is TeX/LaTeX. This would have various benefits:
Sorry I'm so used to interacting with Windows users I forgot. :-(
I'd rather RTF. It leaves us with "pretty" formatting like
"Bold/underline/etc" and I think Linux shouldn't' have any trouble with it??
Or will it ???????
I've NEVER used TeX/LaTeX does it have any advantages over RTF ???
> 1. Since the format is text based, the document could be worked
> on by multiple people (a sub-sectioned document such as this lends itself
to
> easy division of labor) via CVS.
What about just breaking it up RTF gives us the ability to add a little
formatting for readability.
Bold/underline etc.
> 2. LaTeX documents can be translated to other forms of output -- such as
> postcript files for printing, PDF for graphical viewing, HTML for
> the web, etc.
True!
> Oh, and it is much more cross-platform friendly than... Word. :)
I agree!!
> A very good overiew of text processing in this way can be found at:
>
> http://dsl.org/cookbook/cookbook_19.html
>
> And specifically on TeX and LaTeX at:
>
> http://dsl.org/cookbook/cookbook_19.html#SEC301
>
> For Windows folks: http://www.miktex.org
> For the Linux world: http://www.tug.org/tetex
Hmmmmmmmmmm.........convince me :-)) LOL
> While I am not a LaTeX guru (I've barely used it, actually, so I
> would have my homework cut out for me), I would be willing to put time and
> effort into mining the list for all the various design ideas and issues
and organize
> it into a LaTeX document. Is there anyone familiar with TeX or LaTeX?
Are
> there other documentation possibilities that everyone would like to use
instead?
Start mining!!! Whatever format we put it in it's a worth while thing to
do!!!!!
> The only other alternative I can see is to designate one person
> as the tech writer, let that person manage the document in whatever format
he or she
> chooses, and be able to produce it in readable format for the rest of us.
IF we can find someone to do it that would be the ultimate.
He/she could capture the data record it and we could have it on record to
access when ever we need it. :-)
BTW I hate DOING documentation.................doesn't everyone!!!
> Comments/Suggestions?
> Dave.
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST
