Date: Fri, 4 Mar 94 22:16:40 CST
Message-Id: <9403050416.AA13981@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: mitra@pandora.sf.ca.us, jcurran@nic.near.net, uri@bunyip.com
Subject: Re: FTP URL mapping
In message <Pine.3.89.9403041005.A19683-0100000@pandora.sf.ca.us> Mitra writes:
> > Just offhand, how many of these implementations would work without any
> > special handling if the access process was a two-step "change directory"
> > then "retrieve file" sequence? I'm of course presuming that the two
> > components were clearly identified in the FTP URL...
>
> I dont know, what I do know is that the gopher->ftp gateway handles almost
> of the cases properly.
If you knew how many man-hours were burned to get the gopher-ftp gateway
to kinda work you would weep (like I do) at the waste, and pull you hair out
when you think about how those resources could have been better spent on more
productive pursuits. The idea of inflicting this sort of imprecise thrashing
around on all client software developers is not pleasant.
> There are only a few sites, with obscure
> implementations, or using obscure ftp features (like multi-line banners
> without leading digits on each line), that break.
>
> I think, what this means, is that the ftp url is non-optimal, but does
> allow a clever client to retrieve from any ftp server.
This is like saying that a clever person will be able to follow directions
that say "The next meeting is located over yonder". Sure, a few strongly
motivated people will move heaven and earth to find the exact
location of something "over yonder"... but if you can offer more precise
directions like "go north two blocks, then east one block and and knock on
the door of the yellow house" you have provided a better locator... because it
provides less ambiguous directions.
A real problem with the current ftp URL is that it is quite ambiguous.
A lot of the ambiguity is not necessary. At the time the URL is being created
it's creator generally knows things like whether to fetch in binary or text
mode, whether the item being referred to is a document or a directory, etc.
Since you generally know this information at the time of creating the URL, it
would be nice if the URL syntax would allow for explicitly stating this sort
of information.
> I also contend
> that to handle multiple ftp server implementations, a client is going to
> have to be clever anyway - either to follow a complicated URL, or to
> figure out the site its talking to. The problem with a complicated URL is
> that many times its going to be specified incorrectly.
Is it better to have a URL sometimes specified incorrectly or imprecisely
specifying all the locators? Having a syntax that allows for a more precise
specification of the locator and minimizes the ambiguity seems like a win to
me...
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)