Text 443, 121 rader
Skriven 2006-04-24 21:55:17 av mark lewis (1:3634/12.0)
    Kommentar till text 323 av Peter Knapper (3:772/1.0)
Ärende: none
============
 DD> YMMV if you use a shim kludge.

 ml> hunh? what shim kludge are you speaking of? my 
 ml> mailer uses a FOSSIL to 
 ml> contact and converse with remote systems and hardware... 

 PK> The shim kludge of software specifically set up to handle IP
 PK> addresses extracted from a Phone no. field...

 ml> hunh?? sorry but frontdoor doesn't require a shim 
 ml> kludge to draw the IP number from the contact number 
 ml> field in the nodelist... 

 PK> Whatever the software is that translates the Nodelist Phone entry
 PK> field into an IP address is the "shim or kludge" that is being
 PK> discussed. Its irrelevant if that S/W is FD or something else, but
 PK> something is translating it from one meaning (a PSTN Phone number)
 PK> into another (an IP address). THAT is the "shim or kludge".

nothing is translating anything WRT this on my system... the only thing that is
done is that 000- is stripped... other than that, my system operated based on
the existance (or lack thereof) of 000- and/or the ITN flag...

it is all due to the basic configuration... my POTS nodes are configured to
specifically HOLD mail for systems that fly IP flags whereas my IP nodes are
configured to only contact systems that fly the ITN or IVM flags... 

 ml> it never has since the feature/capability was introduced... in 
 ml> fact, at the time that it was introduced, it was perfectly within 
 ml> developing and existing practise ;)

 PK> I suspect what you are saying is that FD handles the data recored
 PK> in the Nodelist Phone number field in a manner that allows it to be
 PK> interpreted as an IP address, which means that FD itself IS the
 PK> "shim or kludge". 

no, what was actually done was that limiting code was removed so that anything
in the "contact number" field was valid... in other words, there was, once upon
a time, specific code in place that validated the entry in that field... that
code was simply removed...

 PK> So in reality it all comes down to identifying what is meant by "a
 PK> shim kludge"..........;-)

that might be an impossibility...

 ml> well, i happen to know that DD was trying to go after 
 ml> the use of the SIO/vmodem package written for OS/2 
 ml> systems by the creator of x00, ray gwinn...

 PK> Which is also a form of shim or kludge, taking a modem "Dial
 PK> String" and interpreting that as an IP address (does Vmodem do DNS
 PK> lookups???). 

yet, no one stops to think that it is nothing but a FOSSIL driver and that the
mailer only talks to the FOSSIL driver...

 ml> my system just happens to have the capability of doing something 
 ml> that your's doesn't... 

 PK> Which is no loss to me because I have no need of doing
 PK> that.......;-) 

hehehe... O:)

 PK> I actually think that nicely describes a "shim" or "kludge". Your
 PK> software is making something designed for one thing think its
 PK> something else so that it can use it...

no, actually, it is my configuration that does that and my configuration is
based on the flags flown and the "country code"...

 ml> hunh? so you are saying that the FOSSIL stuff developed 
 ml> by fidonet and its developers is a kludge? 

 PK> No. I am saying that the original FOSSIL simply passes DATA from A
 PK> (the CPU) to B (a serial port) without a need to "translate" the
 PK> meaning of that data into something else. 

BINGO!! however, in this case, B is not a serial port... so what? that doesn't
make it a shim or a kludge... hell, some years back, i actually built an
infrared unit that i used to transfer data over short lineofsight distances...
my original design was highly proprietary and then i got the bright idea of
simply using the serial signals and transmitting the raw data via my device...
for the most part it worked great... when i quit messing with it, i had wrapped
the serial traffic within a validation sequence in much the same way that the
binkp folk ended up doing since TCP/IP wasn't as fault tolerant as had been
presumed... 

 PK> The fact that SOME FOSSIL implementations (Vmodem notably) need to 
 PK> do something else other than talk to a serial port, which means 
 PK> that is it ADDING to the original task of the FOSSIL (Fido Opus 
 PK> Seadog Serial Interface Layer) by talking to the TCP/IP stack, 
 PK> which is most definately NOT a Serial port.

and that negates or changes the FOSSIL portion of the setup?? no one has ever
said or written in the specs that FOSSIL drivers /had/ to talk to serial port
devices, have they? seems that someone is trying to introduce something in to
evidence that is not available...

 ml> somehow i think they'd all highly disagree with you on that 
 ml> without failure...

 PK> Well I think it would take a fairly brave person to try and sell
 PK> the TCP/IP stack as "just another form of serial port"........;-)

hahaha, why would someone want to do that? that would not be any different than
trying to see shortwave/ham radio as just another form of FM ;)

 PK> But all this coems down to what is meant by "shim" and/or
 PK> "kludge"... 

 ml> almost :)

 PK> You forgot to add "surely" after "almost"........;-)

possibly, yes... maybe i did ;)

)\/(ark 

 * Origin:  (1:3634/12)