[REBOL] Re: ftp scheme (cont.)
From: rotenca:telvia:it at: 17-Nov-2003 16:06
Hi Brett,
> It would be great if Ashley and Carl could run this new test against their
> servers. This one is in source code form rather than a patch.
You come to my side about patches :-)
I did not want to rewrite by scratch the whole ftp protocol, only to
reorganize the code to do better and wider patches.
> I think this is entirely reasonable, so in this latest FTP scheme I've
> changed the logic to use NLST only if parsing of LIST results fails. That
> is, if nothing is returned successfully I consider that an empty directory,
> if something is returned but our parse rules fail then I use NLST. Because
> it is simpler, NLST is unlikely to fail (if it is implemented on the
> server). If by chance both do actually fail, then I raise an error. I've
> also factored out the common logic as I see it into a separate function to
> see how LIST and NLST are so similiar.
Could be, the problem is:
1) user ask a dir read ftp://aaa.bbb.ccc/pub/ the dir is [a/ b/ c d]
2) LIST fails
3) NLIST does not fail
4) user copy is [a b c d]
5) user thinks these are 4 files (he can't know that LIST has failed)
I prefer the custom approach, so the user knows what he is doing and what he
receives.
But now i have another idea: to use the NLST only for file retrieve not for
dir list.
A problem i know with this approach is:
>> probe info? ftp://rtfm.mit.edu/pub/usenet
make object! [
size: none
date: none
type: 'file
]
but usenet is a directory.
> I've also merged the various patches added a little more network logging and
> changed [error? catch value ] sequences to [error? try [catch value]]
> pending Romano's comments on this error handling strategy.
Try [catch blk]
catches almost any throwed or maked errors in my test.
There are only 2 general cases i know in which it does not work, but they are
not presents (AFAIK) in the protocols, so we can almost sure.
---
Ciao
Romano
