read ftp:// error - "Juin" -> "Jun" ?

You've got one on me because there is no depth to my memory - vague or otherwise. <g> As near as I can tell looking at various French sites, I believe that you are correct. Interestingly, the French eBay doesn't abbreviate Juin, but leaves it in tact.

Agreed. I hoped a few would chime in. If not, maybe Monday I'll find a .fr email contributor and write directly. Thanks, Anton. --Scott Jones

Just an oversite, I'm sure, when Sterling was coding the mapping function. Thanks. I believe that the French version will prove incorrect in mapping "Jui" to June.

Kind of like a traditional command line version of FTP? I guess it would give access to more commands that could be used more flexibly, but it would seem to me that to get any sort of automation would then require developing the more complex scheme that is in the current REBOL FTP. Am I missing the point? Thanks for the feedback, and I apologize in advance if I have totally missed the point. :-) --Scott Jones

No. You hit it. you can do; insert port 'help print copy port and see what's supported. I think it's not overly complex to use something like port: open iftp://.... insert port "Type A" insert port "get $data10.reamed.lablog" write %lablog.txt copy port It gives no problems with versioning and allows to deal with different file and text formats. If anyone remembers the old nntp.r, then he will see, that it's the same principle. One integrated protocol for easy access and a second version allowing all features of the server.

You are welcome AR

but

REBOL

I gave your idea a lot of thought yesterday, and realized that a few things would be easier to do with a more direct protocol (like, it would be nice to use the usual ftp directory listing directly, instead of having it get parsed and then reconstructing the list). I thought I could get a primitive version banged out in an hour, but two hours later I was still struggling (I haven't figured out an easy way to adapt Frank Seivertson's telnet to an FTP --- the having to open a second channel really makes ftp an altogether different beast! Maybe extending the exisiting scheme to give the more primitaive info would be easier). I really do "get" your point and think it is a good idea, but the project may be beyond my skills. Maybe, I'll give it another try later on. Thanks for the input, AR. --Scott Jones

After looking at the "PORT .,.,.,.,.,." command in the scheme I was able to to open a second data port and use it. (And I saw that "get" is "RETR".) But after realizing, that I could send simple commands through port/locals/cmd-port, I try now to mate both concepts. At the moment I am searching for a place/variable in the port scheme to store information regarding the ascii/binary mode for reuse. If you are interested, I can send my version. AR

able to

RETR .)

am

I thought I was going to be able to leave it alone, but, alas, once bitten, I find it hard to shake an idea. I worked on it several more hours last night! I looked more closely at the FTP scheme and have a pretty good feel for the way that RT manages the different facets of the scheme. They've instituted some very clever ways of reusing data and ports, or so it appears. I hacked a lot on their version in order to understand the flow. I enabled a custom refinement for ftp, like the http uses for managing POST responses. Then with read/custom, the scheme knows to use the custom hook. In several different ways, I was able to get the command port to insert the commands, like you mentioned, with the cmd-port, then I captured the ftp server output with the second channel sub-port . I mainly only tried LIST and NLST and was successful. (Side note: I used the custom refinement as a way to let the current ftp scheme do its thing, then hijack the set-up at the point where I could start intercepting the second port directly.) Before I did any research, I assumed that ls, get, put, etc were all a part of the specification. Ignorance is bliss, just like not knowing that two ports are used in ftp. Where I need to do more research, and maybe you already know this, is through what command are the more refined commands passed through? Like one of the ones I need the most is "ls -alR". Maybe you know, or maybe I can find it later today. I think having a clean scheme is the way to go. Although RT's scheme is remarkably versatile at a higher level of abstraction, the neat features become cruft in a "down and dirty" interactive ftp version (or so I discovered last night). They have some neat code for managing active versus passive modes, and it would be nice to reuse some of that code. Yes, I am interested in seeing what you have and see how you have done it, either on the list or off (which ever suits you better). Of course, I am happy to share my shameless hacks, but they are very dirty, rudimentary so far (as I said, I was mainly using them as a way of understanding how to do it). I believe you are on to something really neat here for a more interactive and configurable ftp scheme. Thanks for throwing out the idea! --Scott Jones