ORG, GEN [arf3]

Andreas Arff ANDREASA@dhhalden.no
28 Mar 93 12:36:48 +0100


"> " is David Garfield and me am "> > "

> > Current status:
> > Dennis has done some work (I mean coding) regarding
> > 1) the Kernel
> > 2) Idea testing the kernel with a muckettymuck C++program
> > 3) Written drivers for com and parallel ports (don't know how finished they
> >     are, or if it is just old stuff)
> ...
> > Arff
>
> It really sounds to me like you are saying that now that discussion of
> the general design is diminishing that it is time to begin coding.
>
> Please,
>
>         NNN      NNN      OOOOOOOO      !!!
>         NNNN     NNN     OOOOOOOOOO     !!!
>         NNNNN    NNN    OOO      OOO    !!!
>         NNNNNN   NNN    OOO      OOO    !!!
>         NNN NNN  NNN    OOO      OOO    !!!
>         NNN  NNN NNN    OOO      OOO    !!!
>         NNN   NNNNNN    OOO      OOO    !!!
>         NNN    NNNNN    OOO      OOO
>         NNN     NNNN     OOOOOOOOOO     !!!
>         NNN      NNN      OOOOOOOO      !!!

My yes is much more smaller than yours but I belive I have the support from
80% percent of moose, if not more, so I don't feel I have to shout.

> The design phases are:
>
>         1) requirements
>         2) general design
>         3) detailed design
>         4) coding
>         5) testing
>
> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
> haven't yet managed to finish the general design, so we should at most
> be doing some preliminary work on the detailed design and coding
> experiments that are considered, in the long term, junk; but WE AREN'T
> READY TO CODE.

Ok phase one is done. Good. Now let's turn the (moose) steak. General
Design is the next phase, and after that, detailed design. Ok, so far so good.
Dennis is working very hard to put down all his thoughts on paper. It's
going forward I can say. I hope we can see what he has done at the end of this
week. That would be the "general design" wouldn't it? He has taken into account
what has been discussed here lately, so no objection please. There can't be
two captains on a ship, remember.
It is more appropirate that Dennis takes the command now than ever, when it
comes to the general design issue.

Now we have the detailed design. This should be carved out by each sub-group.
The subgroup-coordinators will put the design into a document and from there
to the group-coordinators and from there to Dennis. (Of course he has given us
some orders for what each thing should contain.) If he likes what he sees we
continue working with it til we feel we are finished.

What we needs from Dennis to get things work together is specs. regarding
IPC and events. When he has given us the general design we will continue from
there to make a specification on how things should work together.
There is nothing that stops us start coding now. Take my GUI group as an
example. I'll have to rewrite parts of BIOS (as some others will have to).
But I'm not going to put my first bios code into Moose, I'll have to do some
testing first. These things could be done at the same time as the detailed
spec's. is written.

> If I seem a bit intense about this, it is because I have seen what
> happens to a large project if there is appropriate design before
> coding begins.  In this case, I would expect that if we start coding
> now, we will in not less than two years have something that can be
> compared unfavorably with Windows 3.0, and that isn't good.

Havn't we all? No it won't become a windows 3.0, do you know why. We wont
have ms-dos, we won't have a virtual 8086 running inside our OS. We will have
mem. protection etc. We won't have a world of programmers hateing us because
of beeing ruthless against others!

> I will admit that I, and probably most good programmers, have skipped
> both the general and detailed designs on numerous occasions, but that
> is for small projects of not more than two people and relatively short
> duration.  Lets not make the mistake of thinking it works for large
> projects!  IT DOESN'T!  At least not unless you plan to do it over.
>
This is ment to be a small project. Flexibel and modular, so we can add things
when we need!
>
> I would say that what we need to do now is determine:
>    1) What the kernel will do and what the rest will do.
Dennis is working on it.
>    2) How messages will be sent to objects.  (This has been called
>       ROI.  PLEASE don't think that means it is seperate from the
>       kernel.)
> This more or less defines the kernel.
Let Peter and Dennis talk together and we'll have something there too.

> Then we get then detailed design:
>    1) What are the classes?  Most of the class hierarchy?
The classes will be every sub-group, inheriting from every main group,
inheriting from moose. Don't flame me for this. But it will end up something
like this anyway.

>    2) What are the common methods?
The common methods will be methods for looking into dictionaries, rasing
events etc. Don't flame me for this either!

>    and about 10 times more stuff, most of which probably won't be
>       obvious until we get there.... (or even into coding....)
>
> AFTER that we code.

Still most of us don't read a hardware book and then code a perfectly running
program, mostly because books are bad?:-)

Where shall I put you David? Main-group trashcanemptier? Sorry for beeing so
hard but we need getting organized. There isn't time for chitchating!


I assume I'll get answers from all of you before the end of mars!

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--