To: stik@on-luebeck.de
Subject: Re: STIK: welcome back Q!!                                                      


Hi again, and welcome back!
I'm glad you finally got things working again.

On Sun, 16 Feb 97 12:24:58 E Martin-Eric Racine <q-fun wrote: 
>
----- snip ----- re: q-funk's ISP problems etc
>
>I cannot stress it enough, PPP is what's required today. I really
>don't care if all the European providers give one's choice of any
>protocol. In America (or at least in Quebec), providers bought in
>this new technology called a Computone which defaults to PPP. The
>system assumes the connection will be handled in PPP, so they use
>this simple PAP (Plug & Play) preset:

Actually only a minority of ISPs give free choice of protocols here
in Europe too (in Sweden anyway).  And in many cases the SLIP that
they offer is not a proper implementation, but a SLIrP emulation.
(That apparently does not allow proper identd to work)  I have been
fortunate in finding a provider that does offer true SLIP, but many
in other parts of Sweden will not have this choice.

In any case, Peter has been working on PPP framing for STiK 2 for a
while now, and tells me it is progressing nicely.  This means that
once this is finished and we also get TCP and resolver modules done
(anything happening on this... Dan ??? Martin M.???) then STiK 2
should be operational as a STiK 1 replacement for both SLIP and PPP.

But I haven't the faintest idea about progress on TCP and resolver,
since neither Dan nor Martin Mitchell has mentioned this lately.


>     I don't care to get involved into any new OS (Linux or MiNT);
>     neither do I care in bringing the Elephant OS syndrome to the
>     Atari (I call OS syndrome this situation where the OS gobbles
>     more than half of the available RAM without having loaded any
>     application yet (eg: Finder, Win95)).

I fully agree, and this is one of the reasons why STiK is needed.


>     I just need a PPP STiK and, after talking to many local Atari
>     users at last month's meeting, it's become quite obvious that
>     others share similar views; not wanting a new OS, only a PPP.

Well, its in the works now though the recent conflicts have delayed
progress significantly.


>     However, I *CANNOT* put the blame on Dan alone, as the source
>     code wasn't only given to him. Others could have programmed a
>     PPP capable STiK a long time ago but apparently did not...

Why speak of blame at all...?  There were other things needing to be
debugged and improved, and one man can't do everything all at once.
You can't blame a man for not using all his spare time to implement
the features you want in his software.  It would be different with a
commercial enterprise, but that is irrelevant in connection with STiK.


----- snip ----- re: dedicated STiK soul...

Dream on.  We all have an offline life as well, and nobody is going
to give it up for a full dedication to STiK programming.  This is a
software product, not a religion. ;-)

More importantly, I do not agree with you on the difficulty to get
functional PPP within reasonable time, provided we do it for STiK 2.


>     An added benefit of having a PPP version is freedom of choice
>     since, for many people, STiK forces them to use whichever ISP
>     still has SLIP. More often than not, this single ISP does not
>     offer such a good deal compared to more recent competitors:

I agree, this is important for many STiK users.  I myself was lucky
in finding an ISP providing pretty much what I wanted at decent cost.


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

In any case, a failure at the PPP protocol level should normally be
dealt with like failures at the IP level, by error detection and
correction/retry at higher levels (mainly TCP).  The low-tech errors
he mentioned should not slip through even to the PPP level however,
since physical transfer errors should be handled by error correction
in the actual modems.


>----snip of a proposed folder/file structure----
>    upgraded from the one I had sent by Neil

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


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


----- snip ----- re: final part of STiK folder structure illustration


>NOTE:  all clients specified in stik.env must be fully compliant CAB
>       plug-in modules capable of receiving data usually passed from
>       links, but accessed using CAB's internal addressing format as
>       described in \cab\docs\programm.ing\, when any application is
>       requesting a mailsend or binary fetch (such as sending e-mail
>       to a client's author by clicking on his name in "About..." or
>       getting the latest version of a client by a similar process).
>
>   *** CAB's plug-in implmentation is in ..:\cab\docs\programm.ing\
>       but for some reason, doesn't seem to be on the archive which
>       is found on Flinny's page, only the one found on Alex's page
>

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.


>       When no default_scr was specified, the computer is assumed to
>       be using strictly a local MIDI Ring connection until a script
>       is selected and loaded into STiK.
>
>   *** Other ports than MIDI could be used, as a default local port,
>       but since LAN/Serial2 isn't found on every machine MIDI seem
>       more appropriate as a default.

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.

One test setup I plan to use looks like this:

+--<Modem 2>--[Falcon]--<Midi>--[MegaST]--<Modem 1>--[STFM1]--<Midi>--[STFM2]
|
|
+--[USR Modem]--<Phone line>--[ISP Hardware]--<Internet>

The routing ensures that each packet is sent through as many nodes as needed
to reach its final destination, just as on Internet, though we will have to
introduce 'IP masquerading' to allow all machines to address Internet stuff.
(Unless you already own several IP numbers of course, but that's rare.)
Such an implementation would not really be all that hard I think, at least
not if we keep it a bit primitive to begin with.  Frills can come later.
(Btw: Do you know the _real_ meaning of that phrase? [ancient nordic])


>       Internal communication between users on a MIDI ring could use
>       "midi_user@stik.midi.ring" on either IRC or e-mail clients to
>       recognize "stik.midi.ring" as a local domain. IRC clients can
>       also consider local connections like a DCC type not requiring
>       any server connection, allowing the MIDI ring as some channel
>       limited to 16 users that is accessible simultaneously with an
>       IRC chat conducted over the Internet, possibly indicated by a
>       [MIDI STiK] channel header and using the MIDI_USER as a nick.
>
>   *** More than one DEFAULT_SCR can be specified when a multi-port
>       login is desired like a LAN port for Ethernet, modem1 to ISP
>       and MIDI for localnet, which loads 3 different login scripts
>       sequentially to intiate all the connections.

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.

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.
By 'local' I here mean the entire Intranet, not just one computer.  Such
mini-servers could also be implemented for many other purposes, and may
both need and motivate some extensions to the STiK module interface.
(I'm not sure about that though, pseudo ports may be enough...)

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.
This pseudo network would allow any number of servers to be defined, but
note that only one server of each type should be needed in the local net.
I for example would have all such servers on my Falcon, with my Mega ST
and any number of STFMs under test (I do a lot of that) using them via net.
The normal router code (unaltered!) will then automatically route traffic
to/from each server as and when needed.

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.
This would allow current (and future) IRC programs to chat locally without
any alterations whatsoever.

At first these mini-servers can be quite primitive, implementing only the
minimal subset of the server protocols needed.  But in time we may improve
them to whatever level is wanted and seems appropriate.

By using this approach, every partial step in the development process will
bring us closer to a proper network model approaching the unix standards.
I do not mean we should ever go all the way in this direction.  We could
just as well abdicate in favor of linux/mint instead.  No, we should limit
this approach where we find appropriate.  But at the same time we should
never diverge from this approach in such a way that our clients use network
methods unrelated to those on the Internet.  Your scheme would do that.


----- snip ----- re: suggested format of dial-up script

>NOTE:  $END_SCR can be any string defined in stik.env; either a dummy
>       (empty) or specifying operations to be performed once provider
>       connection has been established, such as VA-STARTing an e-mail
>       or news client for automatic mail check/news download.

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.


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

The programming effort for such an interpreter would be virtually identical,
but the flexibility of use would be considerably greater.


>===RFC STiK q-funk.001===
>
>note that I *know* some TCP variables are likely to be handled
>differently by STiK 2.0, however this new structure has already
>good chances of making it into STiK 1.XX to allow users to load
>different scripts for STIK.ACC instead of being stuck with this
>*one* single default.cfg/dial.scr. Instead, using STIK.ACC, one
>will be able to load a different script/cfg into STiK.

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.

Peter is working on PPP right now.  Dan and Martin M, once said
that they would start on TCP and Resolver modules, but I have no
idea whether they still intend to, or how much they've done.
I can only hope that the've kept at it.

Once those three things are done, STiK 2 is up and running, and it
will then work with every ISP. The dialer for STiK 2 will naturally
include multiple script capability, just like Peters STiK 1 dialer,
and he already has various plans for batch commands too.  Your ideas
and other similar ones have been discussed several times, and it is
practically settled that STiK 2 will have this feature in some form.


----- snip ----- re: various old business

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