Return-Path: <gooseman@on.ON-Luebeck.DE>
Received: from on.ON-Luebeck.DE (on.ON-Luebeck.DE [193.29.188.2])
          by hugin.oden.se (8.8.4/8.8.4) with ESMTP
	  id RAA08579 for <dlanor@oden.se>; Mon, 20 Jan 1997 17:47:13 +0100
Received: (from majordomo@localhost)
          by on.ON-Luebeck.DE (8.8.4/8.8.4)
	  id QAA10156 for stik-outgoing; Mon, 20 Jan 1997 16:30:44 +0100
Date: Mon, 20 Jan 1997 16:28:30 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: stik@ON-Luebeck.DE
Subject: Re: STIK: New proposal: open development of Stik 2.x
In-Reply-To: <Pine.SUN.3.91.970119233122.5189A-100000@zeus.netset.com>
Message-Id: <Pine.A32.3.91.970120145534.18323J-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: stik@ON-Luebeck.DE
Precedence: bulk
Reply-To: stik@ON-Luebeck.DE
X-UIDL: 22428761e235b754aa95a2d1bb3d67c4


On Sun, 19 Jan 1997, Dan Ackerman wrote:

> 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.

This is a very very simplified view of the argument. I'm sure Martin does 
not agree either.


> 	I have 2 things to add to this whole argument.
> 
> 	1. Peter you design makes a byzantine beuracracy look effiecint.  
> You aim for speed , but in the meanwhile cause the whole code to get 
> bloated and unmanageable.  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 

It is obvious, that an interupt driven, modular system cannot be debugged 
as easily as a STiK that simply can be started as a *.PRG by a debugger.
I never stated that it would ! I neither stated that debugging is 
impossible. I removed already more than a dozen bugs from the current 
code, without which it would not even start up properly, and certainly 
not do any IP traffic. I also removed bugs from the UDP code, which is 
roughly the same level as the TCP, only simpler. That for the debugging 
point.

I don't know what you mean about the `byzantine bureaucracy look efficient'.
Nobody expected that modularization would come without any overhead 
penalty. But I strongly believe, that the overhead of the current design 
does not have any significant impact on the speed of the package. I don't 
know either what you mean by bloated and unmanageable. Are you saying the 
code gets to large ? The UDP is only about 15 k of source code, and this
providing all functionality including the 7 (!) calls for receiving data 
(i.e. CNget_block, CNgets, CNget_NDB, ...). The binary is only around 5 k.
And it works ! I just tried the Dialer's remote control facility, which 
is based on UDP.

What sort of text are you reading all the time ? I do believe that there 
are details missing in the docs of the module functions. If you came 
across them, why don't you ask, or suggest improvements. The same if 
you're talking about the sample source code.


> their source.  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.

I hope you're not saying here that I intented to have other people blamed 
for problems !

On the other side I don't know what sort of problems you're talking about.
As I have no problems at all to use the module interface, I consider it 
perfectly safe to write programs for. On the fact that I certainly have 
more information how the interface works, see my documentation related 
statement above.

On the attitude : Are you talking about the fact that Martin's arguments 
did not convince me ? What's wrong with the attitude of keeping a design 
if arguments against it are not convincing ? If not this, which attitude 
do you mean ? Please be a little more explicit.


> 	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.  Well let 

How could you come to that conclusion ?

You seem to ignore that I basically took all the discussion results from 
the last six months and built a new STiK out of them. They were mostly not 
by me ! I also include suggestions into the Dialer, like I've done before.
That much for input from the discussion list.

What do you mean by opening up STiK development ? Do you mean releasing 
source code ? Must I remind you that you rejected the idea of releasing 
major parts of the source code from STiK 1.1x to me ? Using the list as 
a governing body ... hmmmm, what should that mean ? The list governing 
release of source code ? Then you're partly right, I do not intend to 
release the whole source to everybody. Just like you, I'm selective to 
whom I give all the code. But you didn't do it either as a result of a 
list's majority's decision, at least not within the last six months.

Dunno either how you can know whether I gave the V2.0 source code to 
someone else, or not.

For me the list is a means to discuss improvements to any STiK related 
software. If I have a suggestion, I state it and it will be discussed. If 
the suggestion is not worth, it will be dismissed. The discussion itself 
should be words enough to convince the author too, so that he implements 
an approved suggestion. I've followed this scheme with the Dialer too.
If the author however is still not convinced, it's his privilege to veto 
it. If it's a strong point then discussion will continue, until the 
author is convinced too. I always said that I'll always accept well 
reasoned suggestions, and I do not think anyone could give an example 
with which I did not do it.


> 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.  Well them seem to be climbing out 

You must have noted that I always was quite concerned with STiK's general 
design. So if you really were after someone with a more vocal role on 
STiK, why didn't you give me more insight into STiK ? I accept it's your 
privilege as a source code keeper, and I never publicly complained about 
it.


> of the woodworks now!  When you first approached me with your project I 
> said send me your code and I'll send you the current STiK.  You seem to 

Nope, this is not true. If you insist, then I look through all the text 
that went into the discussion list since I've been a member. I keep all 
messages on my workstation. I'm convinced I will not find such an offer.


> 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 

I never said old STiK should be abandoned immediately in favour of the 
new design. Of course it does not work. And I'm sure your response did 
not express 'being talking into trying out'. Do you want me to quote your 
message ? 

If you felt I exaggerated when announcing your support, why didn't you 
complain at the time ?


> that time you've pissed so many people off with your attitude that this 
> has become a perilous position.

Wasn't my impression. I assume everybody on this list is mature enough to 
protest if feeling pissed off by anybody.

The way was that I presented STiK publicly here *after* I presented it to 
you, so that you had the opportunity to say no to the project. After 
presenting it to the list there was less discussion than I expected, but 
quite a few people said they're impressed and issued a go ahead. So I 
went ahead and continued writing code for it. Dunno which way I should 
have pissed people off.

Right now I have the impression that I only pissed off you, for some 
unknown reason (for me, at least), and Martin, for not being convinced 
that his module loading scheme would be superiour.

In fact I felt pissed off by some recent statements by Martin, and, with 
this message, by you, Dan.


> 	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 

There was only one point where I really needed to calm down, and that was 
quite a few days ago. At that stage I was thinking about giving my STiK 
code a new name, leaving this discussion list, and finish the stack on my 
own. But that was only for a few minutes. However, if other people agree 
with your opinion which you expressed here, it might be option to be 
reconsidered.


> the last thing we really need (as client authors) is to try and support 3 
> or 4 flavours of STiK.  Aside from this worry there are also the OXO and 

Ok, so there is at least one point here where we can agree.


> Oregon research stacks tht are in development that if they come out and 
> make their api easily accesible will make this whole argument moot. 

Do you have any more information on those stacks ? I remember having 
heard of OXO, but virtually do not know anything about it. And why should 
it make the argument 'moot' ? Is their goal superior to STiK V2.0's goals ?
We still have a vastly larger base of installed STiK's, which might 
shrink rapidly, however, if we cannot provide Van Jacobson compression 
and PPP soon. 


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------


.
