briany at qldlearning.com
Tue Mar 6 06:24:51 CST 2007
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://
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):
on uploadFile tFile
if (numUploads > 0) then
send "uploadFile tFile" to me in 10 seconds
add 1 to numUploads
put ... into url ...
if (success) then subtract 1 from numLoads
> 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.
> 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.
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode