Text 902, 87 rader
Skriven 2007-05-05 19:27:30 av Maurice Kinal (1:261/38.9)
    Kommentar till text 900 av mark lewis (1:3634/12.0)
Ärende: sln_sf  v0.1
====================
Hey mark!

May 05 12:10 07, mark lewis wrote to Maurice Kinal:

 ml> even from the client's perspective, there's much too much work being 
 ml> done on the wrong side... the client should not have to know anything 
 ml> about the server's directory structure (for one thing)...

Moreso permissions.  The structure shouldn't matter any as long as the file
request matches something that exists somewhere in the directory structure of
the file request server and as long as that particular file has the correct
permissions from the servers perspective then the client ought to be able to
fetch it.  What happens to the file at the client's end is up to the client as
far as permissions are concerned.  Any file on the server only requires proper
permissions from it's perspective and altering them to suit another OS
indicates a problem with the client and not the server.

 ml> knows a filename that he wants and send that filename in a REQuest to 
 ml> the server... it is up to the server to locate the filename and send 
 ml> it or a failure message back to the client...

Agreed.  Furthermore if it can't find the particular request then it should
inform the client the request was not correct for whatever reason (eg doesn't
exist).

 ml> well, binkd is very much like binkley in that it is _only_ a mailer 
 ml> so binkd does require external processes for additional functions 
 ml> like handling FREQs...

So then a ftpd should work for file requests without causing binkd any grief. 
Mind you a bash script that could fake out the phoney-baloney FTN standards to
sucker binkd into transferring the file ought to work too, if that is the
preferred method of transferring a legitimate file.

 ml> because binkley _can_ handle FREQs without need of an external 
 ml> process...

I don't recall offhand.  Seems to me that on the last DOS based BBS I ran it
was Maximus's directories where all the downloadable files were and that squish
was needed to legitimize the FREQ.  Don't quote me on this as it has been too
long for me to recall exactly how that was handled but it seems to me now that
squish was involved somehow.  It was never a big issue to me as most of what I
downloaded at the time had nothing to do with Fido and I used ftp since most of
what I wanted was on ftp servers back then.  Very little has changed other then
the ftp server and client source available these days.

 ml> contrast both of those with FrontDoor which does FREQs as well as 
 ml> dynamic routing and netmail packing...

No such thing exists.  If I am not mistaken FrontDoor is a DOS based POTS only
abandonware thingy.  No?

 ml> the problem is that each and every person/system that wanted to freq 
 ml> a file from your proposed setup would (apparently) have to know your 
 ml> directory structure ahead of time...

Not really.  Depends on how I set it up but offhand placing all available files
for frequing into a particular directory should work.  All the client needs to
know is what files are available.  A readable index file could easily take care
of that.

 ml> and if you decide to move things 
 ml> around, everybody is out of sync and freqs start failing...

Why would I do that?

 ml> has anyone ever called you a luddite? O:)

Yes.  However that is an inaccurate assessment.  I prefer sticking with tried
and true methods until proven there is a better way.  I usually have to prove
myself wrong since there seems to be less and less of adventerous people these
days.  If Fido is an indication of computer hobbiests then I am definetly part
of a vanishing breed.  I doubt that makes me a luddite in the true sense of the
word.

 MK>> some fun with you purists at your expense.  Something to do while
 MK>> we watch this Fido stuff fall into total obscurity.  :-)

 ml> ROTFL! riiiight! ;)

:-)

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: The Pointy Stick Society XXIX - Only one I in teamwork (1:261/38.9)