Previous Thread
Next Thread
Print Thread
Asynchronous file transfers #37625 25 Oct 24 04:40 PM
Joined: Jun 2001
Posts: 11,776
J
Jack McGregor Offline OP
Member
OP Offline
Member
J
Joined: Jun 2001
Posts: 11,776
We're considering adding a new asynchronous mode for FTP and/or HTTP file transfers. But it gets complicated, so before undertaking such an effort, it seems worthwhile to try to flesh out whether and how it would be advantageous to A-Shell developers.

The driving motivation behind it is to somehow minimize the annoyance of waiting for files to download or transfer. One example would be where you have a set of files (images?) maintained on the server that you want to sync to the ATE client. The ATSYNC command is pretty handy for this, particularly when most of the files have already been synced, but if you actually have a significant amount of data to transfer at the start of a session, the user is stuck waiting for the main menu to appear without any sense of how long the wait will be.

If the transfers were asynchronous, instead of the application being suspended waiting for the operation to complete, it could at least potentially monitor the progress and display some kind of progress bar to give the user some idea of the wait. Better yet, it might be able to proceed to the main menu (assuming of course that the main menu didn't require one or more of those files to be transferred, which reveals one of the complications in trying to take advantage of this capability).

Or to take another example, imagine an XTREE containing a few dozen products, each of which has one or more images associated with it that the user can see by double-clicking on the item. If each image set takes a couple of seconds to download, and the user wants to quickly browse among them, it will be somewhat annoying to have to wait a couple of seconds for each clicked item. Pre-downloading them would eliminate the per-image wait but you certainly don't want to make the user wait for all of the images to download before even seeing the product grid, since they might only be interested in viewing a couple of them, if any. So you could start an asynchronous transfer operation, running essentially in background, while the user is studying other information in the grid, with the hope that once they actually request an image, it's already downloaded. Sounds great if it all works according to plan, but it doesn't help at all if the user immediately requests the last image in the grid. (In fact, in that case, the synchronous transfer would be better, since you'd only have to wait for that one image/set rather than for all the others prior to it to be downloaded first.)

In terms of application complexity, this would involve making multiple XCALLs (to HTTP or FTP2) instead of just one. In addition to the calls to queue up a file transfer request, you'd need to be able to check the status to know when the transfers had completed (or aborted), and/or to cancel an operation in progress if the user exits the context to which the downloads were applicable.

Does any of this sound useful? Worth investing time into? Other ideas?

Re: Asynchronous file transfers [Re: Jack McGregor] #37626 28 Oct 24 03:59 PM
Joined: Sep 2003
Posts: 4,154
Steve - Caliq Offline
Member
Offline
Member
Joined: Sep 2003
Posts: 4,154
Hope my comment here is not lost in the flood of replies: But, happy as it is now...

Re: Asynchronous file transfers [Re: Jack McGregor] #37627 28 Oct 24 04:06 PM
Joined: Jun 2001
Posts: 11,776
J
Jack McGregor Offline OP
Member
OP Offline
Member
J
Joined: Jun 2001
Posts: 11,776
Yeah - apparently I hit a nerve on this one! For a minute there I thought the forum was going to keel over from the onslaught! laugh
(But thanks for being persistent enough to fight against the tide!)

Re: Asynchronous file transfers [Re: Jack McGregor] #37634 29 Oct 24 05:27 PM
Joined: Nov 2006
Posts: 2,220
S
Stephen Funkhouser Online Content
Member
Online Content
Member
S
Joined: Nov 2006
Posts: 2,220
I'm not opposed to this idea. It just seems like it could turn into a cow pretty easily.


Stephen Funkhouser
Diversified Data Solutions

Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3