Re: st: Re: Problem with confirm

[Kaleb Michaud <kaleb@arthritis-research.org>]

(Even though my comments are written to Alan, I thought there might be 
folks on the list who might be interested in this subject.)

Alan, thanks for your explanation, and while I understand the many problems 
associated with requesting web files, I respectfully disagree with your 
decision to not have -confirm- work with them (and yes, -confirm new- here 
would seem silly, but not useless).  Primary reason for this is for the 
newer demand of having so many more files, directories, etc all on the web 
for easier access.  This may be the first advantage of using WinXP (& unix) 
over Win2K and previous versions as it recognizes that files on the web are 
like files on your network and don't require "http:" prefix.

More comments below:

At 12:33 PM 5/20/2003 -0500, Alan Riley wrote:

> -confirm- is one of the few commands in Stata that does not attempt
> to access files over the web.  We made the decision for it to work
> the way it does because it cannot be reliably determined whether or
> not files exist across all web sites.
I'm a bit confused about this.  Either your computer can read a file on the 
web or it can't, the return code should be dependent upon that at that time 
(ie. not on internet connection, DNS server, site access, etc).


> Also, what would it mean to type -confirm new file <webfilename>- ?
It would return an error code and you would know you couldn't write 
there.  Just like you couldn't write to a write-protected dir on your computer.


> Some web sites properly return a '404' error code when a file is
> requested that does not exist.  However, others actually return
> a file even when the requested file does not exist.  This is
> because web servers and web sites were designed to be read by
> people, not by Stata.
Ah, now this is the main point.  If the site creates a file after the 
request, then it exists and -confirm file- should return 0 independent of 
that being what you expected.  If an error message occurs, this may not 
work.  This is probably more difficult than what I'm suggesting, but it 
just seems that -confirm file- loses a lot of usefulness for not having 
this ability.  Especially if it triggers an error after only spotting 
"http://"; in the file name (this is an assumption) since there are so many 
ways to have web sites mapped as networked drives, etc.


> As a workaround for Kaleb, he can code
>    tempfile junk
>    capture copy http://www.somesite.com/asdf `junk'
>    if _rc == 601 {
>       ...
>    }
Now I will probably have to use this workaround code in many more programs 
instead of -confirm file-.  Why?  When managing a large databank, we have 
hundreds of files to manage and to keep up to date.  Participants may or 
may not be on the network so having world-wide access to these files is 
important and the web makes the most sense for this (just like -net from- 
can be useful for specific web sites).  Depending on the user's 
location/responsibilities, the path used for these files will change 
(network, same computer path, website).  Lastly, I imagine the code that 
Stata uses for -net from-, etc would be simpler if -confirm file- worked 
here as well (does it also use this workaround when it can't find a *.toc 
file?).

We will definitely manage and I appreciate the explanation as to why this 
code doesn't work in these situations.  My apologies if this came out like 
a rant/whine, it was only written to question the reasons provided for not 
allowing -confirm file- to work on web address like other stata commands.

Much thanks,
Kaleb Michaud
Arthritis Research Center

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/