best downloading architecture - vote 1, 2, 3 or 4

[Josh Mellicker]

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