To: stik@on-luebeck.de
Subject: Re: [4] STIK: Proposal for new side standard for STiK etc.                      


On Sat, 11 Jan 1997 19:19:04 Martin-Eric Racine <q-fun wrote: 
>
>On Sat, 11 Jan 1997 23:05:54 Ronald Andersson <dlanor@ wrote:
>>
>>On Sat, 11 Jan 1997 14:54:31 Martin-Eric Racine <q-fun wrote:
>>>
>>----- snip ----- re: Dan's 'Internet Config' idea
>>
>>What...?   Why should that make it a problem to name what programs
>>to use for e-mail, browsing, etc.  I don't get your point.
>
>It would be a problem if used in the context of being a universal
>config shared by both MiNTNET and STiK. The two obviously address
>things completely differently and have different calls... so have
>the clients specified by this file would be useless, as it's very
>unlikely the MiNT folks will alter their API...

Client calling is not done through the API, so I still don't get it.
As I understood it, the clients should only be named there so that
each can be called when needed from another client, which will then
do this simply by launching the other client program.
This has nothing to do with the API.


>>> Unless STiK and MiNTNET come to share a similar
>>>command/argument subset there could be limitations since on Mac
>>>all clients address MacPPP of FreePPP (both using a similar set
>>>of calls the later being the PowerMac version). Since STiK/MiNT
>>>don't share the same calls, integration of the concept could be
>>>a problem, unless we and the MiNTNET folks get to agree on some
>>>common calls that could simply use different routines depending
>>>on which TCP layer is used (eg: STiK or MiNTNET).
>>
>>No, I think this sort of thing is better solved by the GLUESTIK
>>approach.  A new GLUESTIK will have to be written for full use
>>of the new STiK features of course, but the present one should
>>still work for simpler uses.
>
>You seem to forget the purpose of Dan's proposition:
>To have ANY internet client on STiK or MiNT or any other system
>gather its configuration and script data from the same WWW.CFG,
>since the required data (account, user, modem speed, script) is
>still the same no matter what TCP layer used.

No, I didn't forget.  What you seem to forget is that with properly
programmed GlueSTiK, STiK clients should work identically to how
they work under STiK itself, so whatever config method is then used
with STiK should also work under (a new) GlueSTiK.  How the MintNet
clients adapt to this may be relevant, but is not our responsibility.

Also, the whole MintNet problem only applies to those who want it.
STiK itself works fine under MiNT, nAES and other MTOS relatives.
Why bother with MintNet at all is the question I ask...


>>The MintNet authors will always assume unix-type multitasking as
>>a basic requirement, which we do not.  This makes it unlikely
>>in the extreme that we can ever agree on a common API.
>
>Not *that* unlikely, if we make STiK a bit more Unix-friendly...
>Then I'm sure both teams could agree on a standard config file,
>such as the one I proposed.

Making STiK sufficiently more Unix-friendly to cause the MintNet
authors to side with us would require us to abandon single-TOS and
MagiC, and to make MiNT mandatory so as to use MiNT signals.
This is not acceptable to us, and nothing less would be acceptable
to them, so I see such an API alliance as being impossible.


----- snip ----- re: long config file examples
>>
>>A lot of the things specified in current config files, as well as
>>in your example, will have to be handled differently.  New STiK
>>will allow multiple ports and protocols, so such things as 'SLIP'
>>and 'SERIALPORT' (to mention just two) do not belong in any global
>>config file.  They must be individual per STiK port.
>
>Multiple ports, protocols and modular drivers are a STiK-specific
>thing...

No, AFAIK these things also exist under MintNet, although they are
implemented differently from how we will do it under STiK 2.


>what we're talking about here is to have MiNTNET and STiK share a
>common global data to allow for better interaction and user setup,

Yes, but regardless of methods some of the settings you mentioned
simply do not apply either to MintNet, or STiK 2, or to any other
similar implementation allowing multiple ports and protocols.

There is no reason why a port should have to use SLIP just because
another one does.  PPP, SLIP, and other protocols should all be
allowed simultaneously on separate ports.  And having a single
SERIALPORT definition is no use with a multiport system.  Such a
choice can AFAIK only apply to the dialer, since there will be
little use in accessing two dial-up accounts at the same time.


>not to make each and every TCP layer for Atari follow this one
>single approach since, as already stated, the TCP routines and
>ability to use them are strictly TCP/IP layer dependant.

What has "SERIALPORT" and "SLIP" choices to do with TCP/IP layers?
Naturally the ability to use TCP routines is dependent on the
TCP/IP layer, because without it they don't exist, but I don't
see how we slipped over to this subject.

NB: I am not saying that Dan's idea is not applicable for STiK 2,
    but only that we should not expect a MintNet alliance, and
    that the format of most configs will have to be extended a
    lot from the simple forms we have in DEFAULT.CFG today.

eg: Ports must be defined in a new way since multiple ports will
    be allowed, with different speeds, protocols, etc.
    This could be done like below (just a suggestion):
    
#         Port#  Port name      Parameters (STX DEP)  STX remark
#         -----  ----------     --------------------  ----------
#
def_port    0,   "Modem 2",     SLIP, 38400, 8N1      # SERIAL.STX
def_port    1,   "MIDI",        PPP, 31250, 8N1       # SERIAL.STX
def_port    3,   "Centronics",  PLIP                  # CENTR.STX
def_port    4,   "LAN",         SLIP, 115200, 8N1     # SERIAL.STX
def_port    5,   "Modem 1",     PPP, 19200, 8N1       # SERIAL.STX

The port numbers (port#) thus defined can then be used in selecting
specific ports for various special purposes, without repeating their
settings all over again.  The precise parameters will of course have
to vary, depending on the STX's that implement the port drivers, so
the above should only be taken as a very general example.

Also, do not confuse the above port numbers with BIOS device numbers.
The above port numbers are arbitrarily assigned by the user, for the
single purpose of specifying STiK ports.

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