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


On Mon, 20 Jan 1997 15:47:40 Martin-Eric Racine <q-fun wrote: 
>
>On Mon, 20 Jan 1997 16:28:30 Peter Rottengatter <perot wrote:
>>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.
>
>That has been my point all along. Let's get proper CSLIP, PPP and
>TCP, RESOLVER coded to perfection and integrated into the present
>STiK version (STiK v1.1x --ie: Dan's hack--) and then further see
>how we wnat to improve it for STiK 2.0.

Do you mean that no work at all should be made on the modular STiK
version until everything you mentioned works perfectly in the
non-modular STIK 1 ?

Actually I believe that this would take much longer, than getting
STiK 2 operational and then adding PPP to the SERIAL.STX, because
separate people could work on separate modules.  I was under the
impression that Dan and Martin were both working on some modules
(TCP and RESOLVER), but I guess (from recent mail) that they have
both lost interest...?


>Personally, despite the superb CPX modules you have coded, I don't
>like the way STiK 2.0 is going, especially given how you stubbornly
>refuse to implement anything that deviates from your own vision of
>how STiK 2.0 should be. Feeling protective of your hack?

I don't quite get the point here...

Over the last week there have been discussions on several things,
as a result of which Peter has come to several new solutions on
how various parts of port and account configuration should be
implemented.  Much of this suggested by others (including me).

These suggestions naturally deviate from how he had originally
planned to do things, and will mean major code differences, but
he found the ideas good and decided to implement them.

He has also proved very open to suggestions for speed optimization
and has already implemented a few of my suggestions in the code.
Since few of the list members have shown any interest in assembler
language, I discussed these things with Peter in private email.

So, how many actual suggestions has he actually turned down ?
AFAIK three major suggestions have been turned down.

1: Separating the 'pure' kernel from the basic IP routines, by making
   the latter a separate module, was turned down because a module of
   this kind would not fit into the normal STX interface. This because
   it must be optimized in a way integrated with the kernel, and must
   call the kernel (and be called by it) in ways not used by STXs.

2: Launching the modules by reading them as custom data files, rather
   than by simply using Pexec to launch them (like other programs)
   has also as yet been turned down.

3: Your own suggestion that all STiK config and dial scripts be one
   single DEFAULT.CFG was turned down because it makes no real sense
   with a multiport system. Some of the ideas aired in this discussion
   have led to implementation changes however.

On  these particular issues I happen to agree with Peter's choices,
for reasons that I have stated in several mails now.


>Please *DO* reconsider...

Perhaps he will, but you haven't even specified which issue you mean.
If you just mean that he should be open to suggestions, then you have
your wish already, because he is.


>We're trying to shape a new STiK that will be understood and setup
>by the mere user, not a hacker's delight. And since it has become
>*quite* apparent that you lack experience of either Mac/PC ways of
>doing things, as a point of reference, I strongly suggest you learn
>about such things as MacPPP/FreePPP and the Mac system, which has a
>*very* good level of system integration (I would not consider the
>PC ways to be any good of a model though).

Here I do not understand what you object to, or what kind of change
you are actually proposing.  Naturally we should be open to whatever
good ideas we can find, wherever we find them.  As for the 'hacker'
criticism, need I remind you that the project is still in a stage
where several basic modules are missing, and very much remains to be
done.  This is the ideal time to suggest concrete ideas, but not to
complain that the system is not already comparable to the fully
finished implementations on other platforms.  How could it be ?

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