[Fling] About the cummulative loader...

[Simon Wacker]

2. How do you decide which option to use, skipping the whole loading 
process or just loading the next asset? I have two ideas.
a. Every asset has a flag that tells whether it is required or not.
b. An error is broadcasted. If a listener consumes the error we go on 
loading the other assets because we can suppose that the listener could 
fix the error, if the error isn't consumed we abort the whole loading 
process.

3. I agree with John here that time-outs are needed. We have again 
option a. and b. to decide what to do. A further option may be to do a 
retry after some time has passed.


Greetings,
Simon

John Grden wrote:

> I was talking to Chris about this yesterday and he mentioned that 
> we're finaly at that point in development where we get to write the 
> loading manager ;)
>
> Yes, this is where this application will make it's money:  This is why 
> Asset Manager is so cool.
>
> Some items we have to consider when creating the main loader engine:
>
> for this, let's use an example of loading 10 assets with an AssetLoader.
>
> 1.  Dispatch loaded percentage only AFTER you have all of the total 
> bytes for all items being loaded OR all items that have byte totals.  
> If one doesn't have a byte total or nothing was set in the xml about a 
> files total bytes, then you'll have a preloader that jumps around, but 
> it WILL work.  You just forfeit having it move gracefully.
>
> 2.  Load failing.  What happens when you try to load an asset that 
> wasn't copied to the staging server or the server just isn't serving 
> up (que length issues, saturation of the server/pipe etc)?  You have 
> to be able to assign drop dead timeout whereby you remove the asset 
> that failed to load from the total load OR you simply jump out of the 
> load altogether and generate an error.  Either way, you need to 
> generate an error with the offending file(s).
>
> 3.  startLoadTimeOut and totalLoadTimeOut should be considered here.  
> startLoadTimeOut is the time (ms) that the load engine will wait for 
> an asset to register any bytes loaded.  totalLoadTimeOut is a limit on 
> the amount of time you're willing to wait for an asset(s) to load (it 
> can be either per asset OR on the total load).  If it exceeds that 
> time, you generate an error, remove the offending asset, and continue 
> with the rest of the load.
>
> Now, in talking to Chris about this, he seemed to initially think that 
> having a startLoadTimeOut/totalLoadTimeout built into this load engine 
> was outside of this current goal.  I think it's just because it sounds 
> like alot more work that we planned on.  However, when you look at 
> what I've said above, you see that you can't really do it without 
> these options.  You can't have an assetLoader dying on you silently.
>
> Dying silently can simply be that one asset never loads and therefore, 
> your site never continues because the totalLoad event never fires.  
> So, by shear basic need, you at least have to have a totalLoadTimeOut 
> for the entire package.  Otherwise, you'll just sit there waiting 
> without any knowledge of a problem.
>
> So, that's what we need to write ;)
>
> thoughts?
>
> -- 
> John Grden - Blitz
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Fling mailing list
>Fling at osflash.org
>http://osflash.org/mailman/listinfo/fling_osflash.org
>  
>

-- 
Simon Wacker
www.simonwacker.com
www.as2lib.org
www.hq-heilbronn.de
www.flik-flak.de