Hi,

Time I guess to stick my neck out. 

=== Cut ===
As a result of discussions between Maurice, Bo and myself in LINUX_BBS

Proposal for a Offline Door

What follows is a proposal giving the percieved requirements for an 
independant Offline Door for FidoNet users, as well as having the ability to 
be used as an Offline Door for Web based BBS'es.

Reason for this proposal is that a lot of folks, live in regions where they 
pay per minute/second for thier internet connection, and thus cannot afford 
to read messages while online, regardless of whether they are telneted into a 
FidoNet BBS or a Web Board.

Unfortunately local POTS contactable BBS'es are in serious decline, and no 
matter where you find yourself, long distance calls are prohibative, 
especially when made on a regular basis.

Problems while telneting to a FidoNet BBS system are that these connections 
are invariably slow, and Zmodem transfers over the conection are prone to 
failure, and well, Web BBS'es don't have any offline capabilty what so ever, 
and there are a few of them that I would like to be able to
"connect" to and 
use on a regular basis, ie. Head-Fi and HeadWise - these are headphone user 
communities. 

I propose that the Offline Door be written in Perl, as it is portable with 
minimal effort to all current operating systems/platforms I am aware off.

The packet format should be one or more of those currently supported by 
existingY2K compliant Offline mail readers, ie. QWK(E), BlueWave SOUP etc. It 
does not help having a wonderfull packet format for exchange of messages, and 
there are no readers for that format, and I see no reason to write a offline 
reader as well at this stage, when there exists suitable, if not perfect, 
offline readers such as MultiMail and others. I mention MultiMail because it 
is my Offline reader of choice, because it is available on/for a wide range 
of different operating systems/platforms and supports a wide range of packet 
formats. There might be other readers that are as capable, that I am not 
aware of, so be it.

The door should have the ability to extract messages to and from Squish, JAM 
and MSG message bases, as these are the current "standard" bases in use in 
FidoNet as well as mysql for Web BBS'es.

I propose that FTP, BinkD/P and Kermit be used for the transfer/exchange of 
mail packets.

The offline door must be *MODULAR* in construction.

I see no reason to burden a system operator using a squish msgbase with code 
for JAM and mysql when he uses neither, and has no intention of ever doing 
so.

Example; lets say the system operator runs Squish bases and can support FTP 
and Kermit, and has users who require BlueWave and SOUP packets, then all he 
will need to install are as follows;

Squish module, the Offline door, BlueWave and SOUP and the FTP and Kermit 
modules, and he is a happy camper and so are his users.

This approach also makes/gives the Offline Door a great deal of independance 
and flexability.

There is no need to develop all possible modules at once, for that matter 
there is no need to develop any modules other than those that have immediate 
"use", and others who need support for other formats, can do so
themselves or 
request them with motivation.

Am I making sense. 

More importantly have I forgotten anything. :-((

What we need is a "Universal Door" for mail and file exchange, folks, that 
will allow us to continue our hobby, that will not exclude the "Old
System's" 
and will accomodate the "New Systems".

I think what I have proposed is do-able, now enough with bothering you good 
folks, let me get my VIM cheat sheet "image-less" and lynx
friendly and on my 
web server, and life will improve somewhat. :-)
=== Cut ===

While I am at it, I may as well do the same fot the perl and C tutorials I 
just got off of the Internet, have a better chance of using them if I can 
easily read them I suppose.

Russell

--- GoldED+/LNX 1.1.4.7