• very interesting

    From Maurice Kinal@1:261/38 to Janis Kracht on Sunday, November 15, 2009 16:06:46
    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)
  • From Janis Kracht@1:261/38 to Maurice Kinal on Sunday, November 15, 2009 22:15:06
    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)