read ftp:// error - "Juin" -> "Jun" ?
[1/8] from: arolls:bigpond:au at: 2-Jun-2001 11:14
From the vague depths of my memory,
I think the French reduce "Juin" into
three letters "Jun".
It also seems to make the most sense
to me that way, with regards to
pronounciation.
It would be nice to get a French
person's opinion on this.
Anton.
[2/8] from: gjones05:mail:orion at: 2-Jun-2001 4:56
From: "Anton"
> From the vague depths of my memory,
> I think the French reduce "Juin" into
> three letters "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.
> It also seems to make the most sense
> to me that way, with regards to
> pronounciation.
>
> It would be nice to get a French
> person's opinion on this.
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
[3/8] from: sqlab:gmx at: 2-Jun-2001 13:24
I have a radically different proposal.
Instead of adding all the month's abbreviations (by the way the abbreviation
of Oktober in German would be Okt and not Oct, and these works only for
servers giving back the file list in a Unix-like style..) why not add a new
'iftp scheme.
But instead of supporting all the gadgets of the original scheme take a more
simplistic way and make it more interactive.
That means it should allow "insert port 'command" and just give back the
result with copy.
This way 95% of the user will be able to use the convenient way of Rebol and
the small rest will have to build their solution upon i(nteractive)ftp or
whatever you call it.
regards
AR
[4/8] from: gjones05:mail:orion at: 2-Jun-2001 7:33
From: <[sqlab--gmx--net]>
> I have a radically different proposal.
>
> Instead of adding all the month's abbreviations (by the
> way the abbreviation of Oktober in German would be
> Okt and not Oct, ...
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.
> and these works only for servers giving back the file
> list in a Unix-like style..) why not add a new 'iftp scheme.
<<quoted lines omitted: 8>>
> regards
> AR
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
[5/8] from: sqlab:gmx at: 3-Jun-2001 14:41
> From: <[sqlab--gmx--net]>
> > I have a radically different proposal.
<<quoted lines omitted: 17>>
> require developing the more complex scheme that is in the current REBOL
> FTP. Am I missing the point?
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.
> Thanks for the feedback, and I apologize in advance if I have totally
> missed the point.
> :-)
> --Scott Jones
>
You are welcome
AR
[6/8] from: gjones05:mail:orion at: 4-Jun-2001 15:29
From: AR
> > > I have a radically different proposal.
> > > why not add a new 'iftp scheme.
<<quoted lines omitted: 14>>
> > 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?
> No. You hit it.
<<quoted lines omitted: 13>>
> access and a second version allowing all features of
> the server.
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
[7/8] from: sqlab:gmx at: 5-Jun-2001 13:48
> > >
> > > Kind of like a traditional command line version of FTP? I guess it
<<quoted lines omitted: 37>>
> 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
[8/8] from: gjones05:mail:orion at: 5-Jun-2001 8:30
From: "AR"
> 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.
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
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted