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?
