Text 8023, 109 rader
Skriven 2006-11-16 20:29:48 av mark lewis (1:3634/12.0)
   Kommentar till text 8021 av Maurice Kinal (1:140/13.1)
Ärende: compress.cfg
====================
 MK>> waiting for around 10 years now.  :::sigh:::

 ml> what do you have in mind?

 MK> More or less what I had in mind over 10 years ago which was (is) to
 MK> exploit the tools that are readily available to any Unixie platform
 MK> as opposed to porting DOS-think to Linux.  

i'm still confused as to what you classify as "DOS think"... some things that
you classify as "DOS think" i don't find to be because i've always encountered
them in other OS environments...

 MK> One of the major difficulties would be the headers but I am sure a 
 MK> comprimise could be readily obtainable.  

hunh? are you talking about the binary PKT and stored messages format? that's
not necessarially<sp?> "DOS think" but it is easily overcome by the use of
another PKT format that is detectable and able to be handled by mail tossers...
there are several PKT format proposals in the FTSC archives... some have
example codings and handlers but unfortunately none were ever embraced by any
tosser coders and thus have languished as nothing more than proposals...

 MK> To this day I don't understand why the current employed method is 
 MK> preferred over a purely character based format 

like email and news? the reason is quite simple... no one coded support for it
and thus the populace never had a chance to select it for use... remember, the
standards weren't set by any particular body or group... they were drawn up,
implemented and put to use by the coders... i'm aware of more than one Type3
PKT format as well as a Type10 format...

to implement a new PKT format only takes one to code it and have it
supported... in fact, it doesn't even have to be mainstream as long as you can
get your feed to support it... that could be as easy a task as having their
current tosser create unbundled (ie: raw) PKTs for your system and then they
run a "conversion" tool on them to put them in the plaintext ascii format you
desire... seems that a tool to do such would also be quite easy to implement...
it would just need to read the current Type2 PKT files and move the headers to
the top while converting from binary to text the current binary data...

 MK> especially given that if POTS compatibility is to be honoured then 
 MK> my argument would be that characters have always been a huge 
 MK> factor in most serial programming, which modems where always
 MK> honouring.  

the counter argument to that is that it is faster to transmit e32 than 3634...
sure, that's only one character but the idea is what we're talking about... it
is also easier for programs to work with hex than ascii if the data is needed
to be in ascii anyway...

and before you say it, i don't see how that can be considered "DOS think" ;)

 MK> As far as I know they still do.  Did I miss something somewhere?  
 MK> Last time I checked DOS could handle character based formatting 
 MK> quite well or as well as DOS could handle any other type of 
 MK> formatting.

no, you are right...

 MK> Seems to me that the last decade has only promoted compatibilty
 MK> with abandonware which y2k was supposed to have completely
 MK> obliterated.  

hunh?? if you are speaking of stuff like QWK then what you are actually
witnessing is the average population of users not being willing to give up
their existing and favorite tools and methods... with this in mind,
enterprising souls came up with fixes and workarounds that took care of the
problems and thus the "ancient" software is still operable today... however, i
think you'll see them fall by the wayside in another 31-32 years ;)

 MK> Where are these people who developed all that stuff? Are any of 
 MK> them still in Fido and if so what do they think of where we've all 
 MK> gone with this hobby?

most all of them left fidonet for various reasons... the highest, if one were
to take a poll, would likely be all the b.s. politics... there are still a few,
very few, that are still in fidonet or are comtemplating a return... how they
feel about the existing technology i really can't say but i know that many are
proud of their achievements... some of them actually made advances in the
technology of the time by going off in their little group, coding the new
technology, testing it with their private beta teams and then releasing it on
the masses... in some cases, it was accepted while others never went
anywhere... RIP graphics comes to mind as a "failure"... EMSI, on the other
hand, was accepted and is actively used today...

have you seen the BBS Documentary, yet? it is available from the author for $30
or $40 but it has also been released so that it is free to share... i grabbed a
copy of a DVD rip and have watched it a time or two... it is really an
eyeopener in some cases... i wasn't as surprised at some of tom jennings
statements as i'm sure others possibly were ;)  it could use some more work and
interviews but for what it has it is a great piece of work... i'd like to see
some interviews from folks and developers from other zones... andrew milner,
joho, mats wallin, tobias burchardt, adam hudson, the author of GEcho, and
numerous others... the PCBoard guys were represented as well as the original
Mustang Software (WildCAT!) guys... SEA and wynn wagner III were also
interviewed... if phil katz was still alive or had been interviewed before his
death, he would have also been in it... i'd also like to have seen some stuff
about the userland terminal applications like ProComm and Telix... they even
have a couple of transfer protocol creators in it... excellent story, to say
the least... it is hard to pack all that history in one "show"... there are 8
"episodes" that vary in length from 45 minutes to 20 minutes... i'm thinking,
without loading it up and looking, that there are like 3 ~45 minute episodes
and 3 or 4 ~30 minute episodes and one ~20 minute episode... that gives us
about 4.5 hours if my math is accurate... 20+ years just can't be fully
compacted in 4.5 hours no matter what you do ;)

)\/(ark

 * Origin:  (1:3634/12)