To: stik@on-luebeck.de
Subject: Re: [2] STIK: STiK 1 support vs STiK 2                                              


On Tue, 18 Feb 97 18:31:58 G Nicholas Flintham <list@f wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-
>
>>The only thing I have against Dan investing a lot of time on STiK 1
>>now is that I would prefer him to work on STiK 2 stuff instead.
>
>Wasn't there a discussion a while back about making a release of stik 
>1 with some bugfixes and stuff before everyone got pulled headlong 
>into stik 2 stuff?

Yes there was, and everyone (me included) felt this was an excellent
idea.  But that was a while back now.


>>but rather the opposite.  Since Dan does not seem inclined to favor
>>continued support of STiK 2 anymore the point is moot.
>
>I Beleive that there is Still alot of things which need to be 
>discussed and clarified before Dan and Martin do any actual work on 
>coding things for stik 2...... 

Perhaps, but if so, where are they ?
How can anything be clarified by silence ?

Dan seems completely unavailable now.  In a reply to one of his posts
3 weeks ago I suggested solutions to the function problems he had with
the STiK 2 module interface, but AFAIK nothing was done about it.

Martin posted two mails this sunday, then disappeared again, and still
hasn't answered my request for a description of some of his module
ideas that I then repeated (Having asked for them some weeks earlier).

NB: These were ideas of his that I found very interesting, maybe even
    leading to a solution of the 'loader conflict', and yet he still
    hasn't answered (The original question was posted over 3 weeks ago)

With this rate of communication we'll all be in the grave before things
get 'clarified'.  :-(


>>Again it is ridiculous to use things like these, at this stage,
>>as an argument against the whole package.  Especially as neither
>>you nor most others have presented any constructive criticism
>>(not to mention programming help) on these subjects.
>
>I like the idea thats been banded about about a combined dial.scr and 
>default.cfg file at the moment Actually.. Maybe all of the config 
>stuff could be removed from the main programs and a program be written 
>to handle all of the configuration stuff could be written..

All config code can never be taken out, because every time the kernel
starts it will have to configure both software and hardware.  Thus it
has to read and interpret the config file(s) to know how to do it.
The user interface parts can and should be kept apart from the kernel
and all modules.  Peter as you know favors doing this with CPX's, but
in a release version there should be a non-resident APP doing the same
things, so that COPS/XCONTROL is no requirement.


>A bit like ICE_NET in the oasis 2 package.. once things are setup
>people should  rarely have to load the configuration program plus it
>being seperate saves ram....

That is true and I agree.  It is also true about CPXs of course, since
these are not resident either, although the CPX server is.  Personally
I see nothing wrong with having both.


>People offer constructive criticism a) when they want to 

Ok, if they don't want to they don't have to report at all,
but destructive criticism is not acceptable in any case.

>and b) when they have time..

Sure, if they don't have time they can neither test nor report.
But when they do report they should try to be constructive, at
least to the point of accurately describing any problems.


>Programming.. Well some people on here 
>are not programmers remember :) 

I know, but several are, and a main advantage of the modular design
is that several authors could work in parallel on various modules.


>>Actually I agree that some of the things are too complex for the
>>average user, but that can be made transparent to them later on,
>>by supplying some alternative configurations for non-networkers.
>
>Yep all the tcp parameters should probably be hidden from the average 
>user with only the provider specific stuff being in plane view.. any 
>generic setup stuff like that shouldn't be in plain veiw.. it confuses 
>people too much.

I don't know exactly what you mean by 'hidden' or 'in plain view' here.
The STIKPORT.CPX controls things that are obviously not intended for the
average user at all, so they shouldnt have to use it.  We should prepare
standard setup files for non-networking users with a simple interface
program allowing them to enter provider data.


>>You are a beta tester, so you should know better than to use lacks
>>in an early-stage user interface as reasons against implementation.
>>Reasons for change they may be, but don't just say it is no good,
>>but suggest improved means of doing things instead, like I have.
>
>Being a beta tester doesn't put you ahead of the average user.. I have 
>included people in the beta testers list who are not amazing at using 
>programs and computers just for this sort of feedback...

I didn't say he had to _be_ better, but that he should _know_ better.
Any beta tester does know that he is testing stuff not ready for
release yet, so bugs and awkward features are to be expected. And
even if he cannot describe how to program an improvement, he should
be able to describe how he wants it to work in relation to himself.


>>>>                              At that time Dan stated his intention
>>>>to complete the TCP STX after making such a release ASAP, so the new
>>>>STiK 1 release would keep users happy until STiK 2 could be ready.
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>May I please emphasize that it was DAN who said that, and that he too
>>(apparently) shared this intention at that time.  AFAIK most did who
>>were then discussing the subject.  Later there was a turn-around on
>>this, and a flame-war about it, for reasons I still do not understand.
>
>Dan maybe said it.. I think it was probably said in the same mail 
>about making some stik 1 releases whilst stik 2 gets fully going.

Yes, I think that was it.


>>I have not changed my mind, so I still have this intention, yes.
>>This is not because I am an enemy of STiK 1 (I'm not), but because I
>>am a friend of STiK, and believe that STiK 2 is the way to go now.
>
>Stik 2.... yes I beleive it is the way to go.. were not going to start 
>going backwards in version numbers......

No word games please.  In the present debate 'STiK 2' does not mean only
whatever finally comes after STiK 1.  If you want a different name for
the design Peter made then suggest one, but please stay serious.


>This could be contain quite a bit of Peters code etc Or it could evolve
>from Stik 1... that depends on sorting out the problems people have with
>Peters implimentation 
>imo...

Yes of course.  If everyone decides to kill it, then it dies.
I just can't understand why anyone would want to.
(And overlong delay is the same thing of course.)

And how do you expect these problems to be sorted out when those
who see them as problems aren't talking to the ones who don't.

I'm not talking about the module format stuff now, that's fairly trivial,
and Martin will at least argue the points for or against various issues.
(Though he has been very quiet lately.)


>>I am not going to limit my thinking to fit any mold.  Most ideas I
>>keep getting now are beyond the means of STiK 1 to handle, and so
>>I have no choice but to suggest their implementation with STiK 2.
>
>I dont think Stik 1 is as bad as you think... Quite a bit of stuff 

Not you too !!!
Let me repeat it again:  I have never said that STiK 1 is bad !!!
The drawback it does have is limited extensibility.


>that has been suggested was suggested when stik was still a tos 
>program and steve planned for quite a few of them to be included in 
>later versions... some of them didn't requite much work according to 
>him.. 

Sure, up to a certain point I'm sure this was so.  But some things are
very difficult to add to a non-modular kernel like STiK 1.  I know that
I've seen statements by Dan saying the very same thing, so this isn't
just my opinion.  It is a fact.


>>Naturally it is possible to continue with STiK 1 anyway, and gradually
>>evolve it into an equally capable concept as STiK 2.  Modular and with
>>multi-port support and all that, sure.  But I believe it would be much
>>more difficult, and would consume too much time for it to be meaningful.
>
>As you know im no programmer but I cant see why things like making 
>stik 1 load modules being hard.. 

It is a matter of structure.  Both program and data structure is involved,
and STiK 1 would practically have to be redesigned from the bottom up in
order to get a useful modularity.  It could be done, but not quickly.
Taking something apart and then putting it together again differently
can often take much longer than building the stuff you need from scratch.


>multi port maybe a little harder.. but surely not that much?

No, once the program is properly modular there should not be any real
problem in having variable port modules.  Achieving modularity is the
real problem, since STiK 1 was never designed for it.


>>If the same authors instead cooperate in developing STiK 2, I believe
>>we will have a much better system in surprisingly short time.
>>But no, I don't really expect this to happen any longer :-(
>>(Though I'd be happy to be proven wrong in that.)
>
>Quite a bit of code had already been written to be implimented in a 
>new stik 1 version.. It was decided a while back to finish this wasn't 
>it?

Sure, and I still think it should be done, or rather that it should
have been done because that was some time ago.  Whatever happened ?
He mentioned things already prepared, just needing to be put in and
compiled.  Then, some betas later, it would be released.

Sure, some debugging may be needed, that's what betas are for anyway.
But where are they...?

Don't get me wrong now.  I'd understand if there'd been a snag of
some kind holding up that work, but then he should let us know.
Perhaps one of us could solve whatever the problem might be.


>>That is all very well, he is free to do what he wants, but I still
>>think the user would have had a functional PPP package sooner if
>>Dan had kept working on the TCP STX (should have been done now).
>>Peter could probably have had PPP for STiK 2 already without the war,
>>and under such circumstances I'm sure Martin would have fixed the
>
>Dan isn't writing the PPP layer somebody else is and he has been for a 
>while so this hasn't stopped dan working on and TCP stx.

I knew that someone else was working on PPP (though only by rumour),
but q-funk implied that Dan is working 100% on STiK 1 improvements.
That would obviously mean he isn't working on the STX at all.

Are you saying he is...?  That would be good news.
Is that definite ?


>Martins resolver no matter what format he originally writes it in 
>shouldn't take too much porting to whatever format is decided for
>.stx at a later date surely?

Delaying the coding unnecessarily due to varied opinions on the STX
format is ridiculous.  As you yourself say it should not be very hard
to convert a module to a changed format if needed later.  I agree.
But we have no idea how long it will take to settle all differences
of opinion on this matter, or other similar design details.

That is no reason to let progress stop.
And why scrap Peter's design untried ?
(AFAIK only he and I have used it...)


>>(Not fully debugged perhaps, but well on the way...)
>
>Since nobody has really mentioned this on the list.. how do you know 
>what stage stik 1/ppp etc is at? :)

I never said I know exactly what stage it is in, but I do know people
are working on it and that it is not yet done, that is all.  But you
do make one valid point here, which is that vital STiK information no
longer reaches this list directly, but only by indirect rumour.


>>He's welcome to it (Dan I mean), but I wish he would reconsider his
>>enmity to Peter and the STiK 2 concept.  I still do not see where
>>that came from.
>
>This is for Dan and Peter to sort out between themselves now in 
>private imo.

I hope they will too.


>>I wouldn't say anything like that, though that is probably moot
>>to you, since I do regard STiK 2 as a replacement for STiK 1.
>>Just as any previous STiK version has been a replacement for the
>>one preceding it.
>
>Stik 2 will follow 1.. thats the way you count :)

Yes, but you know what I mean by the term 'STiK 2' without counting.


>>This time it is a rewrite, not just an edited update, and a new
>>author is involved.  So what ?  That too has happened before,
>>though some of the old code has been used for rewrites then.
>>But the only reason this has not been done this time is because
>>Dan changed his mind about it.
>
>>From what I remember Dan didn't change his mind he was always 
>been reserved about some of the detail for the new stuff... 

That is not how it appeared to me.  When he finally did mention
his reservations, he did so in an extremely complicated and yet
vague manner.  I still haven't puzzled out what he really meant.
The only technical reasons he ever mentioned were quite trivial
and should have been solvable with no real difficulty.  It was
just a matter of implementing some more functions to the module 
interface.  I discussed this with him, and he seemed to agree,
but apparently nothing came out of it.


>>I wonder that myself.  He said he had some improvements prepared
>>that he wanted to release, but not that he was starting on any
>>major new developments.  But then he seldom speaks here anymore,
>>so only those (like you) who are part of his new group have any
>>idea of what he's doing.  I find it all rather sad :-(
>
>There is no new group.. Just quite a bit of discussion on irc... 
>Anyone can come and go on #stik if they get registered with the bot 
>first.. you have been yourself... 

Sure I have, and that was not what I meant (as you know).

If q-funk is right about all the NEW development being made for
STiK 1, then someone is testing that stuff, and it certainly is
not happening here.

Surely something is wrong somewhere, when it is only by rumour
that this list knows of the STiK 1 PPP development progress.

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