Let's say you wanted to provide the user with a "splash" or "stub"
app that downloaded a "Main Stack" from a server along with a a
whole bunch of other files to be downloaded to various locations.
There are a few options:
____________________________________________________________
1. the "splash" app gets a whole list of files and downloads them
all, then finally runs the Main Stack
pros: simple
cons: will take too long for the user to begin to be able to use the app
____________________________________________________________
2. the "splash" app first downloads the Main Stack and runs it, but
the "splash" app continues to download a whole list of files in the
background
This would be ideal, but is it feasible to set up a callback
framework where the Main Stack code could check download status and
make decisions based on whether certain files had downloaded yet?
____________________________________________________________
3. the "splash" app downloads the Main Stack and runs it, then the
Main Stack downloads all the other files
keeps the "splash" app simple, but the Main Stack should use the same
download library/handlers, right?
____________________________________________________________
4. the "splash" app downloads a whole 'nother application and runs
it, but continues to download a whole list of files in the background
pros: two apps = true multithreaded operation? :-)
cons: complication of the downloader app communicating with the Main
App through sockets to monitor d/l status
____________________________________________________________
What is your vote?
1
2
3
4
5. none of the above
_______________________________________________
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
