To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: welcome back Q!!                                                  


On Mon, 17 Feb 97 09:09:24 E Martin-Eric Racine <q-fun wrote: 
>
>On Mon, 17 Feb 1997 08:52:03 Ronald Andersson <dlanor@ wrote:
>>
----- snip ----- re: no blame for implementation lacks
>
>Precisely why I wrote this, as I heared many ugly things being
>said about Dan not comming up with PPP, that I wanted to clarify
>that he could not be held responsible for the delays in making PPP
>into STiK, especially since he does this as a hobby and, contrary
>to some of us, has little spare time to begin with. Plus, original
>sources of STiK had been sent to others (one particular individual
>has finally come up with the basic routines for PPP), but had not
>yet manifested themselves.

I never thought you meant to blame him, but just wanted to emphasize
the point that doing so would be unfounded, for those who do.


>>>     ... as I'm writing this addendum, my tech support looks over,
>>>     and suggests we make Van Jacobsen optional as they have found
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>     this compression scheme to cause problems when handling users
>       ^^^^^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^
>>>     who call in from remote areas through low-tech phone lines.
>>
>>I do not quite see how that would be handled, since I do not think
>>the standard PPP package for ISPs that you mentioned has any option
>>for this.  Their PPP probably means VJ packing will have to be used.
>
>Ronald:  again, READ THE ABOVE, they are NOT using VJ and prefer
>         we turn VJ compression OFF!

Who are "they"...?  The manufacturers of that software package...?
If so, they are up the creek without a paddle.  If they do not have
functional VJ in their package they do not have standard PPP.
I have never heard of PPP _without_ VJ being used anywhere.


>>>STiK folder structure
>>>---------------------
>>
>>You do not specify if this structure is intended to be optional or mandatory.
>>I would definitely oppose suggestions to impose any mandatory structure on
>>the users.  If it was merely an example of how a user might organize stuff
>>then I have no objection to that of course.
>
>Yes I do, just like STIK.RSC and DEFAULT.CFG/DIAL.SCR are expected
>to be found in \STIK_CFG\ in STiK 1.XX, as mandatory.

No. none of the STiK-related files are bound to any particular folder,
and even less to any particular structure.  It is all user-definable.
That is the purpose of STIK_DIR.DAT, and I favor continuing that usage.


>>----- snip ----- re: leading parts of STiK folder structure illustration
>>
>>>        |
>>>        +---\tcp\+---cslip.tcp
>>>        |        +---ppp.tcp
>>>        |        +---slip.tcp
>>>        |
>>
>>So what is a '.TCP' file, and what are its purposes and motivations...?
>>I could not see any TCP.STX in your example, so it appears to me as if you
>>want several versions of the TCP module, each married to a lower-level
>>protocol.  If so, I must disagree.  I do not believe this to be efficient.
>
>This was my idea to separate the protocol STX from the port
>drivers by giving them a different extension. As it turns out,
>since the STX are small to begin with and only a commodity for us
>coders, then they probably should all go in \STIK\DRIVERS\

I agree that those with normal modern systems will probably prefer
to have them all loaded (I certainly do), but I still disagree with
the use of that extension. They seem to indicate that those drivers
are only intended for the TCP protocol which is not true.  I see no
particular reason why we should have lots of different extensions
anyway.


----- snip ----- re: exetended CAB interface doc's
>>
>>Ok, I guess Neil told you I had been asking about where to find it.
>>I'll check it out before making any evaluation of it of course, but
>>in the meantime I must ask one thing.  Is the CAB-defined protocol
>>really so terrific that we wish to bind all future clients to it...?
>>I'll have an opinion on that after checking the doc's on it.
>
>Again, as stated in my 1st post yesterday, Martin and Mark have
>ZIPed me a copy of their stik@list archive so I could know what
>happened while I was cut off.

Yes, that's right, that was nice of them.  Still, the important
thing for me is that you do know, and provided the information on
how to find the documentation.  I'll get back to my question on
how good the CAB protocol is after having absorbed those doc's.


----- snip ----- re: multi-port chatting
>>
>>I still don't see why you want to restrict this chaining to such ports
>>that were designed for chained use.  Whats wrong with 'Modem 1' or any
>>other serial port (or parallel for that matter) ?  They may only give
>>a point-to-point connection, but on an Intranet that is just as good.
>>As long as packages are correctly routed from one machine to another
>>there is no reason to restrict any high-level usage to any port group.
>
>Actually, nothing against using other ports. just that the basic
>Modem1 is already used either by a real modem, or by a multi-out
>expander in a MIDI Synthesizer kit.

But with several machines in an Intranet, it is much less likely that
all of the machines will have either a modem or that expander.


>For instance, I wanna be able to leave my Export on my STFM's Modem1
>all the time, leaving only the MIDI or Printer port. Since I also plan
>on leaving my printer pluged in, then using just one pair of connectors
>on my MIDI patch bay allows me to maintain my setup and plug into the
>STE, which has my zoltrix into Modem1 and yet another printer into
>Printer, again leaving only MIDI free. After talking to others, this
>seem to be a typical situation.

Typical for one group of users, yes.  But those who use MIDI for its
original purpose would not agree.  I also like to use MIDI for networks,
since it is faster than the 'Modem 1' port. But if MIDI is used for some
music hardware the only way for chained networking requires using both
the printer port and 'Modem 1' on an ST.


>But as I said, it does not prevent other ports from being used, only
>that MIDI works fine (as demonstrated with games like MIDI MAZE) for
>a small local setup of about 3 machines.

Yes, I know.  The 3125 cps rate is the best that can be achieved with
the normal serial ports on an ST.  But the printer port should be even
faster, so many will prefer that for two-machine networks, especially
when they want to transfer large files.


----- snip ----- re: more on local IRC chatting
>>
>>This is an improvement over your original scheme, and I agree, but I
>>note that you again limit the local network to use ports designed for
>>chained use. I hope you understand that no such limitation is needed.
>
>Again, no one HAS to use MIDI. See above.

Good.  I just wanted to be sure you agreed on this.
I'll stop nagging about it ;-)


>>Also, I would prefer a mini name-server implementation, that would use
>>a single text file to associate each local symbolic name to an IP number.
>
>The local IP is what I called MIDI_UNIT on my STIK.ENV file and
>could use 0.0.0.<unit> as a local IP, with the MIDI_USER for local
>mail drops and local IRC.

I do not think all those zeroes are appropriate for subnet masking.
Otherwise I see what you mean, but want a 'wider' implementation.


>>Each such server could have it's own IP number not locked to any physical
>>port, by defining the pseudo port "Internal" on each machine needing it.
>
>There could be some sort of a polling routine to check if other
>STiK equipped machines are connected to physical ports for local
>use? I guess my MIDI_UNIT and MIDI_USER could be renamed to
>LOCAL_UNIT and LOCAL_USER...

Well, I meant rather that the Intranet could be equipped with
servers of various kinds just like Internet.  These would only
have to reside on one of the machines in the net, but clients
on all machines could use them.  Two obvious servers to start
with are a name server and an IRC server.  Then you could have
all the chatting you want without altering one byte in the IRC
clients, or having to define any 'special' ports or names to
the kernel.


>>I'm not familiar with the IRC protocol, but you may well be correct that this
>>requires the client to know the difference between local 'nicks' and those
>>which must be contacted via an IRC server on the net.  But that requirement
>>disappears if we instead implement a mini-server for IRC more properly.
>
>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...?


If you do not mean that, but do mean for this to be implemented
for STiK 2, then obviously we must have the main parts of it
operational before such servers can be of any use.  Thus, even if
we have to assume that Peter must be the one to implement such
servers he would naturally complete the kernel protocols first.
But the main point of modular design is that others can join in
doing such jobs too, so they could be ready for use/debugging as
soon as the kernel has all the protocols, if someone starts now.


>>By using this approach, every partial step in the development process will
>>bring us closer to a proper network model approaching the unix standards.
>
>One example of such a standard is:
>   NICK (user@port.host) has joined #channel
>That has been the standard in IRCII. The identd stuff also comes
>from Unix, so yes, closer to recognized Unix practices THAT STILL
>MAKE SENSE TO US is for the better, I agree.

Good.  Naturally we must draw the line somewhere in how close to
appproach the unix standard.  We are not trying to clone it, and
there are hordes of things quite inappropriate for our systems.


----- snip ----- re:  commands in scripts
>>
>>That would work, but I'd prefer $END_SCR to be a string for path+filename
>>of a script file, allowing multiple login operations.  I really believe
>>that this would be a lot more flexible.
>
>If you read my RFC, you'll find multiple logins are possible by
>specifying more than one DEFAULT_SCR lines.

And I would still prefer the flexibility of proper batch files.
Btw:  If you want to emphasize things by underlining old quotes,
that's ok, but do try to make it relevant.  I said it would work,
which I obviously would not have said if I'd missed the parts you
now underlined.


>>>END_SCR      = prompt ("Login:  Connection Established"[Check Mail
>>>               {d:\internet\ant_mail\ant_mail.prg:chk_mail}[Ok{exit})
>>
>>I believe you mean that this should generate a dialog box, containing the
>>prompt and awiting a user response.  I feel sure that this would not satisfy
>>those who prefer fully automatic mail transfers etc.  Other commands than
>>the 'prompt' example would naturally be needed, and these would really be
>>better implemented as part of a script file interpreter.
>
>see ^^^^^^ above. The $END_SCR could be: VA_START something, just
>show a "connected!" dialog, download mail/news drop, etc.

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 ?


----- snip ----- re: getting the above stuff into STiK 1

>>Sure, it could be done this way, but then time must be taken from
>>the really important development, thus delaying it instead.
>>As you yourself have emphasized, PPP must have priority, and to
>>me this means we need a cooperative effort on STiK 2.
>
>Already being tested on STiK 1.XX... You seem to assume everyone
>has already dropped work on the present STiK 1.XX scheme, or has
>adopted Peter's 2.XX design verbatim. I do not recall anyone who
>said "Okay, STiK 1.XX is shit, let's trash it and get 2.XX done"
>except for yourself...

I'll deal with the facts in the above further below, but first:

---------------------------------------------------------------
You've actually succeeded where  none in this list have before.
You've managed to make me angry.  No, furious is a better word.
---------------------------------------------------------------

Do not lie about what I've said again.  Everyone in this list knows
full well that I have never said anything downgrading about STiK 1,
though I have stated that I believe STiK 2 has greater potential.


As for whether or not Peter's design should be retained "verbatim"
as you call it, that depends mainly on whether people argue for
meaningful improvements, or just act hostile and abusive.


>Anyone else feels like telling Dan, Mike, Martin and others
>involved in STiK 1.XX their work is useless?

That is another thing I've never said, and never will...
You are not exactly improving your reputation for veracity...
(nor my temper)

I wonder what you think you achieve by lying about what I've said.


>Certainly not me! In fact, I'm working on a new dialer/RSC using
>the STIK.ACC (since Dan has now sucessfully transfered every old
>STiK function into the TSR) only as a user interface to STIKTSR,
>as a control panel for PING, FINGER and TRACE modules being done
>and as a mean to handle the login. DEFAULT.CFG/DIAL.SCR are most
>likely be renamed into PROVIDER.SCR. The ACC will allow loading,
>using a simple button, of another script for those who have more
>than one provider account (thus provider.scr instead of default,
>and hence why the DEFAULT_SCR in STIK.ENV).

Ok, very nice.
Now, what has that got do do with lying about my statements ?


>But I'm still interrested in seeing Peter's hack succed.

Really...?
You have a very strange way of showing this interest here.


>All I'm saying is, let's not trash 1.XX just yet, as Dan already
>has made quite a few improvements and cleaned up many of Steve's
>original mistakes.

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.
Dan should certainly know that, since I did it in reply to one of his
mails discussing these things.  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.


>Why not just add PPP to it

Because getting this implemented and debugged takes a lot of time,
and in the end we're still sitting there with a non-modular single
port system.  There is nothing essentially bad about that, except
that we now have a chance to set our aims higher.


>and then see where we want improvements and THEN work on 2.XX
>TOGETHER (not just on the STX)?

Why not do it now, so we can take advantage of results sooner ?
We have been talking of major improvements for too long to just
keep talking.  The time is ripe (overripe even) to get it done.


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

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