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


On Tue, 14 Jan 1997 13:27:35 Martin-Eric Racine <q-fun wrote: 
>On Mon, 13 Jan 1997 15:14:59 Peter Rottengatter <perot wrote:
>>On Sun, 12 Jan 1997, Dan Ackerman wrote:

----- snip ----- re: Dan's suggestion of a new client launch info file

>>> 		I bet you are wrong on this.  I've hesitated to put
>>> somethings into Antmail that would cause problems for GlueSTiK users.
>>> This would get around that.  I'm certain that Rojewski feels the same on
>>> this as he's probably seeing a large part of his user base becoming
>>> MintNet users.  After you have actually written a STiK client yourself, I
>>> think your attitude would shift.
>>
>>My guess programmers won't use those strings comes from experience with
>>CAB. STiK had those HTTP_PROXY and so on variables quite early, but Alex
>>ignored them and instead invented the wheel again, this time inside CAB.
>
>Just because Alex decided on reinventing the wheel, does this mean
>we all have too? I personally would MUCH prefer getting all the
>relevant info from the environment variables in STIK.CFG than having
>to manually input all account data into each and every client.

That is one way, as functional for us as Dan's proposal, which was that
each program wanting to use the info should read the new info file itself.
This was obviously to make the info file and its use independent of STiK.


>This would also save everyone a LOT of needless coding of those various
>"set mail account data" menus and dialogs!

No, because such data is not necessarily constant.  With Antmail it is
quite possible to access any number of different mailboxes anywhere on
Internet without even redialing, provided you have the appropriate
data for each of those mailboxes (password etc).


>The only exception I can see to this are IRC clients, which store an
>impressive list of IRC servers, currently up to 20 in aIRC's case,
>so in this case, dropping the UP_RESPONSE, which was mainly used by
>Steve's old IRC client, made perfect sense.

Agreed.  This sort of thing should be in a client-specific file.


>But to have the SMTP/POP/IMAP/NNTP servers and user data (ie: POP
>Password, UserName, etc.) into the STIK.CFG makes absolute sense,
>I think both Dan and John would agree that it would also save the
>users the trouble of inputing the very same data in all 3 clients
>(especially given that some of us have to change providers rather
>often as each and every one drops SLIP in favor of PPP over time)
>and therefore make things more user-friendly! ;-)

No, these do not belong in a STiK config file, because the mailbox
you access does not have to be specific and constant even during a
single dial-up session.  But I agree that all clients that need a
mailbox data configuration should use identical setup files, so
that one can switch between mailboxes in these clients simply by
choosing the appropriate file with the file selector.  That is how
Antmail does it, and the others need the same capability so they
should either use the same files (.SET), or a new standard should
be defined to be used by them (including some future Antmail).

Because such a mailbox switch does not imply, nor is implied by,
any other change in STiK parameters, mailbox data should not be
mixed with them.  Instead I suggest that some new STiK config
variables be created to define the default boxes in a way that
allows all clients to find them:

SMTP_MAILBOX_DEF = dlanor.set
NNTP_MAILBOX_DEF = dlanor.set
etc...

These variables should be allowed both in the config file of the
TSR itself and in the dialler script files.  Since the default
mailboxes you want may vary depending on the ISP you dial.

For similar reasons _all_ user data related to dial_up accounts
should also be controlled by similar selections allowed in both
the main TSR config and in the dialler script, since you can't
normally have the same username and password etc on each ISP.

Note that in a multiport system the 'local' IP will vary, and
will depend on the port routing, and actually this should imply
similar changes to other default account data.  I mean mainly
CLIENT_IP, USERNAME, HOSTNAME, NAMESERVER.

I'm sure Peter is aware of all this and has been working on a
new standard, but let's not stop discussing such ideas just
because of that.  Some of it may even inspire him to improve
on his plans for doing things, though much will have to be
adjusted to allow for STiK's new multiport nature.


>Smile everybody! Smile! Welcome to STiK Island!

Ok, here we go...  :-)

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