Hey Janis!

You may have noticed that I've moved this discussion to here. Offhand I am guessing it is a good idea.

I did some testing here and it did work for bluewave archived
packets.

First I had to set my GF (grab format) to BlueWave in the
Utilitey menu

I saw that and at one session did change it but changed it back to text after since I couldn't find the grab via ftp. However ...

zip file was in my telnet program download directory when I
exited.

down/testgrab.su5

Errrrr ... where is that wrt the chroot jailed directory? Also the text archive doesn't seem to require a telnet login and can be tweaked into action with either a wget or ftp login given a username and password which makes it perfect for scripting into a client.

The only outstanding problem is the uploaded reply's expected filename and format.

However I am willing to try the more traditional method of offlining as long as
it doesn't require zmodem. In that case I am going to have to know where to upload to and if an ftp session cannot work without telnetting then I cannot see how any of this will be of any consequence.

For my part I'd rather leave the faking it to the DOS-think people and totally get rid of anything other than 8 bit characters in the headers, etc. and then use transfers that are less hoggy resourse-wise than faking out a serial connection - especially nonstandardized ones - on a tcpip connection. We both know this is doable since we've done it this way in the past. In that case it was Fido formats but the actual transfers of those pkt's was ftp. That worked better, no doubt about it, and I was tranferring raw Fido compliant pkt's. I still have the scripts here that generated those but personally would much rather to ditch the headers for ones that stuck to purely 8 bit characters and strings (<- null terminated) not unlike what I see in the BBS's echo bases. Far
more standardization there with REAL standards as opposed to FTN so-called standards that aren't standards and never were. The whole argument about backwards compatibilty is a joke at best.

Like I've been saying all along, I am in no rush about any of this, and if I am
just here to repeat past mistakes then I'll stick to the way I am doing this now. Seems to work excellent all things considered and doesn't require ANY DOS-think to be compatible across the board. No faking either. :-)

Life is good,
Maurice

--- BBBS/LiI v4.01 Flag
* Origin: Prism bbs (1:261/38)

Hi Maurice!

You may have noticed that I've moved this discussion to here. Offhand I
am guessing it is a good idea.

Sure, it's fine :)

I did some testing here and it did work for bluewave archived
packets.

First I had to set my GF (grab format) to BlueWave in the
Utilitey menu

Boy did I spell utility funny there.. ha.. somedays I can't see I swear!

I saw that and at one session did change it but changed it back to text
after since I couldn't find the grab via ftp. However ...

All I did was change my GF and AF to zip.. then when I issued the md -m command
to start the download, bbbs took care of everything. I saw a flash on the screen that said something about 'downloading testgrab.something'. After I logged off the bbs, and exited my telnet "dialer" program (I use BBBS's own terminal, it's a free terminal program), the testgrab.su5 was in the download directory I had set up.

zip file was in my telnet program download directory when I
exited.

down/testgrab.su5

Errrrr ... where is that wrt the chroot jailed directory? Also the text

I'm talking about on your own hard drive.. bbbs starts the transfer automatically and sends it to you.. My terminal program was written by the same
author so it knew what was going on .. :)

archive doesn't seem to require a telnet login and can be tweaked into
action with either a wget or ftp login given a username and password
which makes it perfect for scripting into a client.

I didn't try it with text, but I bet it would be the same :)

Take care,
Janis

The only outstanding problem is the uploaded reply's expected filename
and format.

However I am willing to try the more traditional method of offlining
as long as it doesn't require zmodem. In that case I am going to have
to know where to upload to and if an ftp session cannot work without telnetting then I cannot see how any of this will be of any consequence.

For my part I'd rather leave the faking it to the DOS-think people and totally get rid of anything other than 8 bit characters in the headers,
etc. and then use transfers that are less hoggy resourse-wise than faking
out a serial connection - especially nonstandardized ones - on a tcpip connection. We both know this is doable since we've done it this way
in the past. In that case it was Fido formats but the actual transfers
of those pkt's was ftp. That worked better, no doubt about it, and I
was tranferring raw Fido compliant pkt's. I still have the scripts
here that generated those but personally would much rather to ditch
the headers for ones that stuck to purely 8 bit characters and strings
(<- null terminated) not unlike what I see in the BBS's echo bases.
Far more standardization there with REAL standards as opposed to FTN so-called standards that aren't standards and never were. The whole
argument about backwards compatibilty is a joke at best.

Like I've been saying all along, I am in no rush about any of this,
and if I am just here to repeat past mistakes then I'll stick to the
way I am doing this now. Seems to work excellent all things considered
and doesn't require ANY DOS-think to be compatible across the board.
No faking either. :-)

Life is good,
Maurice

--- BBBS/LiI v4.01 Flag
* Origin: Prism bbs (1:261/38)