To: stik@on-luebeck.de
Subject: Re: STIK: STIK config files                                                     


On Sun, 26 Jan 1997 23:13:32 Neil Jones-Rodway <nj1@uk wrote: 
>
>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 version 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


>\stik\env\stik.env
>------------------
>ALLOCMEM      = 200000
>REPORT        = 0
>MIDI_UNIT     = 0  (Host=0, Remote=1-15)
>MIDI_USER     = q-funk
>DEFAULT_SCR   = eclypse.scr
>END_SCR       = prompt ("Login:  Connection Established"[Ok{exit})
>MAIL_QUEUE    = d:\internet\ant_mail\outgoing\
>FTP_CLIENT    = d:\internet\cab_ftp\cab_ftp.prg
>GOPHER_CLIENT = d:\internet\cab_goph\cab_goph.prg
>NNTP_CLIENT   = d:\internet\cab_news\cab_news.prg
>SMTP_CLIENT   = d:\internet\cab_mail\cab_mail.prg
>WAIS_CLIENT   = d:\internet\cab_wais\cab_wais.prg
>
>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).

You are referring to some documentation that I do not have.  In the release
I have there is only documentation for the CAB.OVL interface and for an AES
message system to be used by other clients asking for services of CAB. I can
not find any documentation on the internal addressing stuff you mention, nor
any specification of how a plug-in module should work.

Possibly I have missed something, so please name the precise file which does
cover the stuff you are talking about.  In the meantime I must ask one thing.
Is the CAB-defined protocol really so terrific that we wish to bind all the
future clients to using 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.

I do not see where or how that default was tied to the MIDI port.  There may
very well be other ports in use simultaneously, with different defaults needed.
Whatever settings are active for one port, whether by default or not, should
not affect any setting whatever of any other port, or in any way limit its use.


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

I think I see what you mean to achieve here, but I think it needs to be done
in a more general fashion.  The benefits should not be limited to one port.
It may instead be better to allow some kind of configuration script setting
up certain symbolic names for internal association to internal IP numbers,
so that such URL requests never get passed to any external nameserver, but
are instead resolved internally.  This can then easily be used for any ports
simultaneously, by adjusting the new script as well as the ROUTE.TAB file.

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.  Even so, I think it
should be done in some fashion not limiting this usage to any specific port.

In either case it is my impression that an IRC client implementing this will
also have to have some of the functionality of an IRC server, in order to allow
chatting on a purely local network.  Thus it could make sense to implement a
separate mini-server for this purpose. Then any user connected through any port
could log in to this for chatting to any other user.


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

>WAIT         =
>REPT         =
>FIND         = Your address is
>RESP         = $GET_IP
>WAIT         =
>REPT         =
>FIND         =
>RESP         = $END_SCR
>***========EoF========***
>
>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.

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