Hello Bo.

09 Jun 03 22:02, you wrote to me:

 MG>> You can make it output text based configs as usual, but the
 MG>> advantages of a GUI interface are ease of use, as it can be made to
 MG>> use global commands, which can save a user of the tosser a lot of
 MG>> mindless repetition work, especially if one has a large setup of
 MG>> echos.

 BS> The Squish setup is quite simple, so we big is the need for a UI to do
 BS> the setup?

Yes; that's what most sysops would find handy; it makes the setup process
much easier, and also helps a lot when you need to make some major changes,
like changing mail feeds.

 MG>> By outputing the traditional SQUISH.CFG and ROUTE.CFG files,
 MG>> it would be backwards compatible, and would satisfy those who prefer
 MG>> to use the text configs. A GUI interface can do other things as well,
 MG>> like create a custom batch file to call the tosser, set message base
 MG>> limits, or check and repair damaged message bases.

 BS> Yes i see.. but if you're a programmer you could code it, and i guess
 BS> wes will include it in the source...

If I was a programmer, I would have been trying to create something like
this a long time ago. Unfortunately, I am not a programmer, and because I
am far too busy in my career as a dental technician, I cannot afford the
time to learn how to program. I am however a long time user of Squish, and
know it's capabilities quite intimately as I have been using it as a major
mail hub for four FTN's for several years now, and I often listen to what
my downlinks would like to see in a tosser package. This is what I am
trying to put forth for those who can program and do care to take the
development of Squish further down the line.

 MG>> The ticker is an afterthought; not everyone needs one. I believe NEF
 MG>> is open source now as well, and it has some integration with the
 MG>> SMAPI.

 BS> Do you have a link with the sources?

Yes; you can find it at the original author's (Alberto Pasquale's) website:
http://www.apworks.com/download.html

Peter Knapper did a minor update on Alberto's original sources, and
released his version as NEF/pk.

 MG>> But not everyone is satisfied with hpt, and not everyone is solely
 MG>> interested in Linux development. You need to stop thinking in
 MG>> traditional Linux text-based config terms, that sort of thing turns a
 MG>> lot of potential users of a program off; that much certainly has been
 MG>> shown to be true with hpt.

 BS> Squish's setup has always been textbased, so why change it? I guess the
 BS> users has been very satisfied about it.

Not all have. Many find it difficult to set up and configure, and they turn
to products like FastEcho, Gecho, or Synchronet with it's integrated
tosser. The program works well, but if you aren't familiar with what all
the utilities are and what they do, and what all the configuration options
are, it can be very frustrating to some sysops trying to set it up and run
it. As one small example, many people who use Squish don't even know that
you can have message read buffer sizes of up to 256 kb, and quite often run
up against the default DOS 16kb limit. Some sysops simply will not take the
time to learn everything, and it is a shame, because they will miss out on
what I feel is the best tosser out there.

 BS> And there is nothing wrong with HPT, i used by the most mailhubs around.

Not so; many of them still use Squish and Sqafix, and at least one I know
of is still using Gecho. I am a hub, I use it, my uplink uses it, and many
other hubs I know of use it. I've looked at hpt, but it is a pain to set it
all up, and I see no need for the configuration of a tosser to be so
complicated. About the best thing it's got going for it is that it's stable
and provides access to the Squish format for Linux users. Linux is not the
only OS out there though.

But are mail tossers just for mail hubs? What about the average sysops?
Shouldn't they be able to use the best software available, even if they
aren't technical wizards? What I'm saying is, it's not only important how
well a program works, but it's also important how /easy/ it is to use. You
can have the best, most stable program in the world, but if it takes hours
of pouring over documentation and a high level of technical expertise to
properly configure it, then only a few highly skilled individuals will ever
use the program.

 MG>> I feel any decent development should be a multi-platform approach, as
 MG>> it allows the sysops freedom of choice. SQAFIX is an excellant
 MG>> program, if it could be integrated tightly with Squish in a GUI
 MG>> interface, it'd be even better.

 BS> The main case it's that the shit works? A GUI is not everything.. hm..
 BS> maybe if you ask microsoft it's..

It's a tool that makes the program easier to use. If you make a program
easier to use, more people will be willing to use it, and that creates more
interest in the program and more impetus to keep developing it. If
programmers insist on having a "purist" type of attitude towards
what has been undoubtedly shown to be a useful tool, and refuse to even
consider it simply because they care only about how well the program works
and not at all about how easy it is to use, then they do the program
development a disservice, IMO.

That's my two cents worth. YMMV, of course...

--- GoldED/W32 3.0.1