Richard,
If you're uneasy about your current workaround, here are a couple of
ideas that might help:
1) You could use a blocking shell() command to do the uploads and
avoid libURL for this particular task.
Example: get shell("curl -T uploadfile -u user:passwd ftp://
ftp.upload.com/myfile")
2) Assuming you wrap the upload in a handler, you could possibly
track the number of uploads running and avoid running more than one
at a time. If one is already running, another could retry in 10
second (or whatever interval):
global numUploads
on uploadFile tFile
if (numUploads > 0) then
send "uploadFile tFile" to me in 10 seconds
else
add 1 to numUploads
put ... into url ...
if (success) then subtract 1 from numLoads
end if
end if
HTH,
Brian
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
2) Using the non-blocking form (libURLFTPupload or download), in
concert with a "wait until messages" line thereafter, would also be
effected by pending messages.
Canceling all pending messages, then resending them after the
transfers, helped a great deal. Keep in mind all of these transfers
are occurring under strained wireless conditions outdoors over a
distance of up to 500 feet, with a signal that can drop briefly at
any time. We have to structure all of our transfers with
considerable robustness to repeat the transfer over and over again
until it is successful.
We've also discovered that the built-in Rev file transferring
methods (both blocking and non-blocking) cannot simply be
immediately repeated if one fails during a transfer attempt... at
least not with Rumpus ftp server software and OSX. The server
(under its default settings) rejects subsequent attempts unless we
unload the url, send a QUIT command, and wait some period of time
before starting the next attempt. We're still trying to come up
with a reliable approach to guarantee any downloads or uploads work
every time, even if it takes five attempts.
Richard
On Mar 5, 2007, at 10:46 AM, Dave Cragg wrote:
On 5 Mar 2007, at 16:25, Richard Gaskin wrote:
There's a blocking form for uploading and downloading available
in libURL, and in the last several versions includes callbacks so
one can update a progress indicator or do other minor
housekeeping. Would that help your situation?
I haven't quite grasped Richard's problem of the pendingMessages.
But I doubt it would make a difference whether using "blocking" or
non-blocking url routines. The so-called blocking routines are
only "script-blocking". i.e. they block the currently executing
handler, but will allow other asynchronous activity. (For example,
clicking on an active button during a download, or presumably
executing anything put on the pendingMessages queue before the
"blocking" routine was called.)
Generally, anything on the pendingMessages queue will execute
during an FTP file transfer, if it's due to be run at that time.
Depending on the message, it might interfere with the transfer.
For example, a long repeat that exceeds the socketTimeout interval.
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
_______________________________________________
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
