One of the problems we've encountered is that in the pending
messages, we need to regularly check a directory on the server. That
procedure is, I believe, always a blocking call. I haven't figured
out a way to do it as a non-blocking call. So that short process
itself interferes with current blocking FTP transfers (unless I
cancel that pending message and re-schedule it for immediately after
the current transfer).
Another issue we've encountered is that transferring very small text
files (a line or two of text) via the wireless connection seems less
stable and more difficult to verify when using the non-blocking ftp
calls rather than a simple "put url xx into url yy" form. I've also
found it difficult to reliably compare file sizes of the original
file to the received file for these very small files.
Tied into this is that getting a directory from the server is
obviously just as prone to failure as getting any file from the
server since it's all a wireless call either way and the signal could
drop at any time. What's the most reliable way to verify that the
directory call went through correctly? Seems the only way is to check
"the result", since the contents of a given directory could be empty
to begin with (meaning we can't compare the value that comes back to
see if it is empty, since it might have been empty to start with).
It's unclear of the issues we are encountering in repeatedly trying
to get a directory if prior attempts fail. Can/should a directory ftp
call be unloaded (i.e. via unload URL) before trying a second time?
Thanks for the feedback below Dave.
Richard
On Mar 6, 2007, at 6:03 AM, Dave Cragg wrote:
On 6 Mar 2007, at 11:29, Richard Miller wrote:
Here is from our experience. I can't explain why this is
happening, but repeated tests show that it does.
1) Using the blocking form (put url xx into url yy), we
experienced that a foreground file transfer that might take 30
seconds would be effected by a pendingmessage file transfer
scheduled to occur sometime during the time frame of that
foreground transfer
I see a potential problem here, but it depends what you're doing in
the file transfer pendingMessage handler. When using blocking calls
(get url, put ... into url) only one transfer can be processed at a
time by libUrl. If you attempt to start another transfer before the
previous one completes, you will get an error in the result.
Depending on how your file transfer handler handles errors (Can it
dstinguish between an error in a currently uploading transfer and
one that has been called before the previous one completes?) it
could get messy.
I don't think using the pendingMessages queue to schedule blocking
transfers is the best approach. Typically, you would wait until one
transfer completes, and then start the next one.
If you know the files to be transferred when you start the
procedure, I would do something like this (error checking points
only indicated):
on fileTransfer pFileList
repeat for each line tFile in pFileList
put <whatever> into tUrl ## your url setting routine here
put url ("binfile:" & pFile) into tData
## check the result here in case of local file error
repeat 5 times ## or however many times you want to try
put false into tFailed
put tData into url tUrl
if the result is empty then
exit repeat
else
put true into tFailed
end if
end repeat
if tFailed then
## perhaps record the file name
## and show a list of failed uploads later
end if
end repeat
end fileTransfer
If you don't know the files in advance, then I'd add them to a
queue (perhaps a custom property or global or script local
variable. Then have the transfer routine check the queue when it
finshes a transfer.
local sFileQ
on startTransferRoutine ## called only once, perhas at startup
send tranferFile to me in 0 milliseconds
end startTransferRoutine
on qFile pFile ## adds file to queue
if pFile <> empty then
put line 1 of pFile & cr after sFileQ
end if
end qFile
on transferFile
if the number of lines of sFileQ > 0 then
repeat until tFile <> empty
put line 1 of sFileQ into tFile
delete line 1 of tFile
end repeat
put <whatever> into tUrl ## your url setting routine here
put url ("binfile:" & pFile) into tData
## check the result here in case of local file error
repeat 5 times ## or however many times you want to try
put false into tFailed
put tData into url tUrl
if the result is empty then
exit repeat
else
put true into tFailed
end if
end repeat
if tFailed then
## perhaps record the file name
## and show a list of failed uploads later
end if
end if
send transferFile to me in 1000 milliseconds
end transferFile
The server (under its default settings) rejects subsequent
attempts unless we unload the url,
For non-blocking calls, you must unload the url, even after an error.
send a QUIT command, and wait some period of time before starting
the next attempt.
That doesn't sound too good.
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
