To: stik@ON-Luebeck.DE
Subject: STiK 1 support vs STiK 2 support


On Mon, 17 Feb 97 19:18:06 E Martin-Eric Racine <q-fun wrote: 
>
----- snip ----- re: ISPs using PPP without VJ
>
>"They" are Megacom.net technicians, who prefer NOT to enable VJ,
>for reasons stated above, and yes there are MANY providers who
>use straight PPP without VJ compression.

Ok, if you say so.  Any PPP implementation must nevertheless have VJ
implemented to work with the majority of ISPs, but making it optional
is no problem of course.


----- snip ----- re: port choices for local networks

Ok, preferences will always differ between users anyway.  This isn't
important as long as we agree that all ports can be used for this.


>>>Mini built-in FTP/HTTP/NNTP/SMTP/POP servers have been discussed
>>>before and do not seem to attract too many people...
>>>and would this not further delay coding of Peter's hack?
>>
>>What hack?
>>
>>If you mean STiK 2, then it seems you actually expect to get all
>>the stuff you speak of with STiK 1.
>>
>>Is this for real...?  You can't really believe this.
>>Since when did STiK 1 support multiple ports...?
>
>Yes, Peter's hack= STiK 2. Where did I ever implied multi-ports
>were possible with STiK 1?

You implied it by using a derogatory term about STiK 2, implying
that you certainly couldnt mean that to be the TCP/IP stack you
would want your chat system to run with.


I do not think relations in this list are improved by calling the
software of other members 'hack'.  You don't have to laud it to
the skies either, but try to use neutral terminology at least.
If you wan't to criticize a program do so by arguing the facts,
not by your choice of names for it.


>>I still think this way of doing it is awkward.  What is wrong with
>>naming a batch file that can contain as many commands as the user
>>wants ?
>
>Nothing wrong with it. Would you care to draft a proposal to this
>effect? This actually sounds very interresting! ;-)

Several suggestionss have already been made, and some of the things most
agree on are commands to launch programs with arguments and the ability
to expand environment variables in commands.  Personally I'd also like
some loop constructs and conditionals, as well as batch arguments.
Your idea of using a command for a GEM dialog could also be useful.

In short: the usual stuff needed in any good batch interpreter,
          possibly augmented by some STiK specific stuff.


----- snip ----- re: What I said vs What you claimed I said
>
>Well, this is just it:  every upgrade you propose seems directed
>only towards STiK 2, not STiK 1, hence why you make it sound like
>1 does not deserve much of any further improvement.

The original goal of our discussions has always been that a future
STiK should be achieved with superior quality, even if it took a
complete rewrite to do it.  Even Dan has spoken so on this subject.
(And note that I said 'a STiK', not two, or three, or a dozen...)
When Dan (apparently) approved of Peters work and agreed to start
work on the TCP STX, I certainly took this as an indication that he
too agreed that STiK 2 (as I will call it) was the way for us to go.

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.
So it is not because I do not value his work that I want this,
but rather the opposite.  Since Dan does not seem inclined to favor
continued support of STiK 2 anymore the point is moot.


----- snip ----- re: new STiK 1 dialer etc.

>Just to show improvements are still being done to STiK 1 and that
>I still see pptential in the monolithic, single-port STiK 1. Yes,
>it is rather basic, but I guess my main gripe about Peter's design
>is that I find its user interface rather cumbersome.

At this stage such a comment is ridiculous.  If you and others had
been prepared to join in the programming effort it might have been
different.  With a single author having to do it all it's surprising
that the interface is as good as it is.


>Specificaly, the multi-port parameters are on the edge of user
>friendliness and spreading things over 3 CPX (and possibly and
>upgraded dialer, if I understood Peter's Docs well) makes this
>even harder to picture, when configuring the package. Same with
>ROUTE.TAB.

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.

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.

I have also suggested to Peter that some of the settings that now
must be set in a CPX should be moved to ROUTE.TAB too, and with
supplied default files this means the average user will never have
to open that CPX (or any).

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.


>>I myself have already stated to the list that I favor at least one
>>additional release of STiK 1 with those improvements Dan has prepared.
>
>But WHY just one or 2 more releases? THIS is where your intention
>of eventually eliminating STiK 1 shows again, repeated in the bit
>below:
>
>>                              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.

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.


>>PS:
>>  I think some people have wondered what I'd do when really angry,
>>  since I've managed to keep my temper for quite long.  Today you
>>  have your wish, because right now I'm really boiling mad.
>>  (Anyone who missed why should reread this mail again.)
>
>Well, my intention was definately NOT to angry anyone, but I am
>really seriously pissed off by this attitude some have of keeping
>all of their ideas geared towards STiK 2,

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.

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.

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


>while Dan and others are working towards offering PPP to the average
>user using a single provider/port/modem connection, by implementing it
>into STiK 1,

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
resolver code as well by now.  So we'd already be up and running.
(Not fully debugged perhaps, but well on the way...)


>along with your excellent idea of a batch file for checking mail
>and performing other tasks at bootup or when initiating provider
>link on the login.

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.


>So again I APOLOGIZE IF I OFFENDED YOU. And I definately do NOT
>intend on making anyone look like a bastard.

Good.  Perhaps I'd better explain one thing about myself...
It's not what you said that angered me, but that you distorted
what I had said.  Claiming that I had said things that I haven't.
That will set me off anytime, even on fairly innocent subjects.
(Though the degree of anger is dependent on subject importance.)


>But seeing you and others imply that STiK 1 is only a temporary
>candy until STiK 2 gets done, is what MAKES ME SERIOUSLY ANGRY!

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.

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.


>If a simple monolithic STiK 1 really does not have much future,
>then why is Dan improving it still?

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 :-(


>If STiK 1 was really slated for "Folder 13", then Dan would have
>dropped development on it, and worked on his STX contribution,
>wouldn't he?

That is what he said he would do before he changed his mind,
though he wanted to release some prepared changes first.
I still have no clear idea as to why he changed his mind.

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