FTP access via a port spec

scheme: 'ftp host: "ftp.site.com" user: "Username" ; and yes I set those right ;) pass: "Password" ] But says absolutely nothing about how to specify the file to manipulate. Trying to read from such port results in an error :

** Script Error: read expected source argument of type: file url object block ** Where: halt-view ** Near: read ftp-port I tried all kind of stupid things such as "read ftp-port/index.php3" but did not get much further. And I found nowhere in the docs how such "ftp port" could be actually used. This is very surprising since I can't see the interest of being able to open a ftp port if it can't be used... So I'll have a few questions regarding this "experience" : - would anyone know why does Rebol maintains an opened port despite the fact that the 'read is over ? - does it make sense to use a port spec to access a ftp server ? (assuming the answer is yes) - how can I specify the file to operate upon ? - what does it mean exactly to have an open port open on a ftp server : is it simply an open TCP connection or is it something more elaborate ? I am currently having a very strange feeling about Rebol, it is very powerful to use but the documentation seems insufficient to me on some points like those, which makes it quite painful to do even very simple things. It can be very frustrating at times to see that the documentation opens a new path to explore but does not go any further : there are handlers, schemes and protocols but not much is said of how to build one, what features this or that one provides, and so on... It all seems very powerful but also very osbcure and I would like to know if this feeling is shared by other people on the list ? Thank you in advance ;) Best regards, Laurent -- Laurent Giroud [laurent--giroud--libertysurf--fr]

Well it looks like I am going to answer to myself :) After writing this mail I suddenly remembered that one should not use 'read or 'write on ports but 'copy, 'pick or 'append instead. So I tried this :

== [%cgi-bin/ %index.html %index.php %index.php3 %moncompteur.txt] Which worked fine. Doing the same thing by adding a "target: %index.html" in the port spec definition allowed me to access any of the files individually : great ! I can now download and upload to the ftp server at will, but another question comes to mind now : how does one rename/delete files or directories using a port spec ? Is it even possible ? And if it's not, is there another way to do it via ftp when the username contains characters which are illegal in a Rebol URL ("@" for example) ? Thanks, Laurent

You sound pretty frustrated. The documentation is sparse or not completely helpful in some areas. In this case you were just one slash away from practically being there. page: read [ scheme: 'FTP host: "ftp.site.com" port-id: 21 target: %/index.php3 user: "[myusername--site--com]" pass: "mypassword" ] An alternative approach is to patch the code that parses more readily used ftp code by adding "@" as being valid (watch for line wrap). net-utils/url-parser/user-char: union net-utils/url-parser/user-char make bitset! #"@" With this patch you (hopefully) would be able to do something like: print read ftp://[myusername--site--com]:[mypassword--ftp--site--dom]/index.php3 This patch may break with a future REBOL, so be aware. There is some additional explanation http://www.escribe.com/internet/rebol/m10936.html

I think that the mail list is the quickest way to get answers when the documentation isn't helping. You are not the first to complain about the documentation, and I doubt that you will be the last. It can be frustrating at times, but I have found the rewards of REBOL to far outweigh the frustrations. Your mileage may vary, of course. :-) I would encourage you to hang in there, and feel more free to use the mail list. --Scott Jones

If you open a tcp:// port, that's all it is. If you open an ftp:// port, it knows what scheme to use so you can insert and copy data against it. In this case, the scheme would know what the standard FTP port is. Now, having not done this kind of thing myself, what I say is pure conjecture. I would think that you could insert commands to it (e.g. RETR) in a dialected manner, but that doesn't seem to be the case. FTP ports don't seem to support INSERT. I should leave this to those who know more about ports in REBOL. :) << I am currently having a very strange feeling about Rebol, it is very powerful to use but the documentation seems insufficient to me on some points like those, which makes it quite painful to do even very simple things. >> I think a lot of people feel the same way. The problem stems from little holes, like the one you ran into, that prevent it from working transparently. When you have to dig in, there is often not a clear set of docs on how certain pieces work under the hood. How painful you find it is relative. :) Given any large, complex, software system of any kind, how easy is it to understand, modify, and extend? I always thought VB was easy to use, but I started with QB and lots of stuff just came with time and experience. Newcomers could be overwhelmed very easily by it. What about .NET or Java? Perl, Python, Ruby? Others? Are there missing pieces that will help make REBOL more accessible to "power newcomers" who dig in a bit and then hit these kinds of walls? I guess I'm saying that I agree but, like others here, I'm looking for where we get the most bang for our buck (i.e. ROI). REBOL is so different, in many ways, that I think sometimes it just takes time to get comfortable with its idioms and learns where the traps are. :) << It can be very frustrating at times to see that the documentation opens a new path to explore but does not go any further : there are handlers, schemes and protocols but not much is said of how to build one, what features this or that one provides, and so on... >> Agreed. There are a few examples. This list, and those who know where the hidden treasures lie, and invaluable. REBOLForces is also chock full of great info in the articles and 'zine areas. Hopefully the new FAQ and Library projects will help in this regard as well. --Gregg

Thank you very much ! I was hoping that there would be some simple (but hidden) way to tune rebol to obtain such a thing but had no idea were to look for it. Reading your explanation, I understand that nearly all parts of rebol can be somewhat tuned or modified so higher level components (ie the rebol surface briefly described in the documentation) can adjust to your needs and constraints. The only problem being that the documentation does not give any hint that it can be done and how to do it. Thankfully enough, this list seems to contain enough rebol knowledge to answer a zillion of questions ;) I sometimes wonder for how many time people on the list have been working with rebol to gain such knowledge ? The article you pointed to clearly shows that you have been experimenting quite a lot ! This inspires me a little reflexion (no more than 2 € cents worth probably) about the nature of rebol : it looks like to me that the Rebol approach is very different from other languages, whereas they tend to present the user with a low level interface that he may "augment" by including or coding higher level components Rebol does just the contrary : it offers a high level interface to many standard protocols and data types. This interface suits the beginner needs quite well (if he has access to a good documentation system such as this list) and is ok during the time necessary to get used to the lisp-like ""syntax"" and learn how to use the most usual datatypes and functions. More advanced users can then gain more control over Rebol not by "augmenting" it with external components but by actually digging deeper into it and changing/tuning the system elements already provided by Rebol. My frustration arises from the fact that the documentation seems to ignore completely the "layer" structure of Rebol : it describes some high level elements, gives a little glimpse of lower level ones but without explaining how they relate to the former ones. I guess that it would be much more efficient if it was itself structured into layers : a first one describing all high level element, a second one dissecting those components into their distinctive elements and the relations between them, and so until reaching the lowest level (ie native functions and language interpreter). It is surely a daunting task since Rebol seems built of a big number of such layers (at least it looks like to me !) but it would surely benefit the entire community and help Rebol lose the kind of "toy language" image it has amongst many developers who only swear by open source Python, Perl, PHP, etc. languages. Does that looks meaningful to you experts ?

Be sure I will :) Many thanks again for the quality of your answers. Regards, Laurent -- Laurent Giroud

I agree that it should do it, but it looks like it doesn't. The code below does not explicitely open a port since as you say it simply reads on a scheme, however when looking at my firewall status window it shows that port 21 is kept open by rebol. tiftp: [scheme: 'FTP host: "ftp.host.com" port-id: 21 user: "username" pass: "userpass" target: %index.php3] print read tiftp But couldn't it be a bug in the ftp protocol ?

I do agree and as I said in my answer to Scott Jones (oops, sorry I don't know which word is his first name ?) I think rebol would gain a much wider acceptance in "open source language" developer circles if there was such documentation available.

Perhaps that writing the documentation that Reboltech failed to write is the best way to increase your ROI by making sure that knowledge gained by individual old timers can be transmitted to all other rebolers be they themselves experts (in some other rebol domain) or beginners ;) The list is of course a very good way to exchange ideas and comment rebol code but I guess that you could all become tired as rebol will gain wider acceptance and newbies will arrive on the list always asking the exact same type of question everytime ;) Many rebol related sites I visited offer part of the knowledge that you evocate but perhaps would it be better if all their owners partnered to write "the alternative rebol documentation". It could take the form of a book (electronic), where G. Scott Jones could write the chapter on protocols and handlers, Brett Handley could be responsible for the view/vid chapter, Ladislav Mecir would take care of lower level interpreting mecanims (if I understood what it wrote on his site ;)) and so on (random name selection from some of the list recent active subjects). Of course this is a beginner's dream, but perhaps it can be done ;) Regards, Laurent