To: stik@ON-Luebeck.DE
Subject: Re: [2] STIK: New proposal: open development of Stik 2.x                            


On Sun, 19 Jan 1997 23:42:48 Dan Ackerman <baldrick@ze wrote: 

Dan, I hope you won't feel I'm butting in on this issue, but I have been
rather heavily involved in the discussions you refer to below, and I can
not let this mail pass without remark.


>As I look back over the discussion for open development of STiK what do I 
>see?
>
>	I see it degrading down into a fight over one person arguing to 
>save a few bytes here and another arguing it would be a wast e of time.

No Dan, that is only one small part of the argument concerning the module
loading method.  If that had been all that was involved, I would not have
bothered to write all those replies and explanations to Martin.  I really
do understand his views too, since I was originally of a similar opinion.
It was after Peter convinced me of some of the merits of the Pexec method
that I really started thinking about it,  and found several more reasons
that actually makes it more flexible and to some extent safer than others.
I will not bring them all up here too, except to mention that they are the
reason why I have felt it necessary to defend this method.


>	I have 2 things to add to this whole argument.
>

You addressed the section below directly to Peter, but I was so puzzled
by parts of it that I have to ask you to clarify what you really mean.

>	1. Peter you design makes a byzantine beuracracy look effiecint.

I see the reference, but not the analogy.  In what way is the design so
inefficient, and what particular remedy needs to be implemented ? Do you
mean the basic idea of modular general purpose drivers, or some specific
implementation detail(s)/method(s)...?


>You aim for speed , but in the meanwhile cause the whole code to get 
>bloated and unmanageable.

Peter and I have had several discussions on various means to achieve
speed optimization (some in the list, some in private mail), but have
agreed that the right time to make such optimizations is when the new
code is functional.  Trying to do it earlier than this would be a waste
of time, since the so optimized code would have to be replaced, over
and over, as part of the initial debugging phase.

So, for the present, the only things that should be optimized are the
design choices that allow full optimization later on, and the interrupt
driven routines in the kernel.


>I know you argue this point, but I must say I'm spending alot of time
>reading alot of texts rcently to see if your  current design can even
>be considered safe to program for.  I see the very great possibility of
>bugs popping up with no way to easily trace their source.

I'm very uncertain of what you mean here, so my answer may be irrelevant
if I have misunderstood the intent of your statement.  The greatest risk
factor that might introduce bugs difficult to trace is of course the very
fact that the kernel interacts with various modules simultaneously.  But
that is true to some extent of any TCP/IP stack allowing such modules,
and the only way to avoid it completely is to keep the entire code of all
protocols, port drivers, etc, in a single program.

That method is the one used so far for the STiK we already have but, as
you of all people should know, it places much too heavy a burden on the
one who must maintain the code.  This was already the case with the STiK
1.xx package, and it would become far more so with an attempt to add all
the improvements we've planned into a future STiK of similar design.

So modular design of some kind is more or less unavoidable in order to
give STiK the capabilities we want.  If you think that there are some
particularly unsafe parts of the module interface, please name them, so
that safer alternatives can be developed.


>I'm certain from your attitude in the last couple of weeks 
>that it inevitably will be blamed on someone other than you peter even if 
>it was the general design that was the problem.

Well, I don't not what may have passed between you and Peter in private
mail (he's not mentioned anything negative about/from you), but judging
from the debate in this list, your comment above is uncalled for.

Perhaps he did grow a bit irritated in the debate with Martin lately,
but to some extent I can understand that.  Being called 'reticent' is
one thing (can be an honest mistake), but being called 'recalcitrant'
is something else.  That's really insulting, and I disliked it myself.
Martin later said that this wasn't directed at me, and I believe him,
but I was irritated at the time, and I believe that Peter was too.


>	2. The original argument is being ignored.  Most of the people 
>that were oringinally involved with STiK (sans Steve who is linkless)
>had all argued for opening up STiK development and use the list for a 
>governing body.  You seem to be completely against this idea.

I'm not exactly sure of what you mean here. A committee cannot program,
only individuals can do that.  At best a committee (of any kind) can be
helpful for coordinating the efforts of various programmers, and serve
as a 'think-tank' for developing new ideas.  Both these things can also
apply to coding details of course, but in the end it is still a person,
not the committee, which must create the actual code.  The dangers of a
'governing body' of this kind are mainly two:

1:  If no individuals are responsible for implementation, a committee
    usually degenerates to pure discussion, with no tangible results.

2:  With source free for all, lots of 'third-party' STiK versions with
    various patches may appear.  These will not be written by the more
    'serious' list members and will therefore probably be buggy, and
    may destroy the reputation of STiK (thereby reducing the user base).

NB: I'm not arguing against the 'open' system here (I'm undecided on it).
    I'm just presenting two potential problems with it.


>Well let me inform you that I'm not the only person with the code and if
>one of the others decided to go ahead with it there is nothing that you
>or I could do to sto them.  I've often wondered in the past why none of
>them had taken a more vocal role in STiK.

Probably because they were not so dissatisfied with the progress being
made that they wanted to take on the effort themselves.


>Well them seem to be climbing out of the woodworks now!

Martin, you mean ?  Yes, I know he was involved with STiK quite early,
and he certainly has been very vocal in our recent discussions.  But
to me it doesn't really matter when or how anyone here started working
with STiK.  What matters more is that he does have some useful knowledge
and experience of networking and other STiK related things, which should
enable him to contribute to the new STiK system.  The fact that we are
currently on opposite sides in arguing about the module loader does not
have anything to do with my (or Peter's) recognition of his abilities. 


>When you first approached me with your project I said
>send me your code and I'll send you the current STiK.

I agree that this would be a fair exchange, except that Peter did not
have much finished code.  Most of the project was still in the idea
stage at that time.  I'm quite certain that he would not object to
your having a copy of his source, though I also know that he does not
believe that public source releases are a good idea.


>You seem to have forgotten this when you announced my full fledged support
>to the list.  I allowed myself to be talked into trying it out, however
>since that time you've pissed so many people off with your attitude that
>this has become a perilous position.

Who ?
Perilous how ?
Does this mean you will _not_ support Peter's STiK 2 design ?

I only know that Martin dislikes the module loading method used by Peter,
but I see no reason to believe that he'd let this degenerate into personal
dislike and an inability to cooperate.  To assume this would be such an
insult to him that I would need to know it for a fact before doing so.

The other people you mention should also tell us what it is that they
dislike so much, so that we can discuss possible solutions.  As long
as they don't speak up, their opinions can't affect anyone else.
This is like complaining about politics, but refusing to vote.


>	So what we need to do now is to take a step back, calm down the 
>egos a bit o all sides and see what we can do to patch this up.  About 
>the last thing we really need (as client authors) is to try and support 3 
>or 4 flavours of STiK.

I definitely agree.


>Aside from this worry there are also the OXO and Oregon research stacks
>tht are in development that if they come out and make their api easily
>accesible will make this whole argument moot. 
>(translation worthless).

I definitely disagree.  I know nothing about 'Oregon research' and have
only seen the 'WebSpace' browser demo from 'OXO'.  Nevertheless, any new
TCP/IP system coming out would have to catch up with STiK 1 first,
both in regard to client support and in gaining users.  And that may in
itself not be so easy to do.  And once STiK 2 gets to the point where it
can function in place of STiK 1, we can start working on the improvements
that motivated its creation.  So, if all goes well, I believe that STiK
can stay ahead of the competition.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
