[Fling] About the cummulative loader...

[Chris Allen]

Hey Guys,

I do agree that timeouts are indeed needed. I have a different idea
then Simon, which might work just as well.

The AssetLoader should hav a flag that tells it whether to abort on
error or to continue. So a property called abortLoadingOnError:Boolean
with a default value of false would work.

The next step is to add a timeout value to Assets. The problem with
this is that most of the asset types that we are loading time out by
themselves at some point. XML is an example of this. Are there any
that won't throw an error if it doesn't find the asset or has trouble
loading it or some reason? We could write a unit test to check that
all of these throw errors appropriately. I think that would be
valuable.

Thoughts?

-Chris


On 5/24/06, Simon Wacker <simon_wacker at gmx.de> wrote:
> 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
>
>
> _______________________________________________
> Fling mailing list
> Fling at osflash.org
> http://osflash.org/mailman/listinfo/fling_osflash.org
>