In a flurry of activity last night I added remote downloading of textures; right now it only works with http or ftp requests but as i'm using libcurl I can pretty much deal with anything; I probably need to refine my 'is this a url?' detection; I wonder if ':' is a valid character in any file systems?

Today I added async downloading; this was just a matter of pointing the async routine at the Sync libcurl based loader as there really didn't seem to be any other way of doing it. It might be possible to hack something together with events but for now this seems to work just fine as the loader is in another thread anyways so it doesn't matter so much if it blocks.

Now matters switch to that of loading errors; before today if a file didn't exist things would just asplode and you'd find yourself in Debug Town so I've got to the loading routines and added various error checks and exceptions so that the loading can fail cleanly.

This brings up an issue however; how to report the errors?
Right now, the exception is consumed, the image's status set to 'error' and the client has no further information about the error. It could be a load error, a parse error or anything like that if simply doesn't know.

So, the question becomes do we want to give back more information and if so how?

Right now I'm not really sure how I want to go about this, and with the added consideration of a callback system when loading 'completes' being throw into the mix it just complicates matters further. This requires further pondering.

The other thing I'm thinking about is the ability to define custom decoders; the main reason this could prove a problem is that it requires exposing some internal code to the external world. Mostly it's a short refactor to shift things about, but mostly it's a matter of doing it cleanly. The fact that some of the functions are templated, such as the image flipping routines, and thus need to be resolved at compile time is also a slight pain.

So that requires some consideration; given that the library is redistrubted as source and covers the major image types I don't see how added an extra decoder could be handy, the ability to define your own loaders however is useful as the library only understands file or url sources.

So, the march towards 'complete' carries on, of course once that is done we aren't at the end of this saga as the core needs refactoring out and seperating so that an audio loader can be added, thus forming an asset loader.

[pete@slow:~/tmp]
283> mkdir http:

[pete@slow:~/tmp]
284> echo zxcv >http:/qwer

[pete@slow:~/tmp]
285> cat http://qwer
zxcv

[pete@slow:~/tmp]
286> ls -lR
total 9
drwx------  2 pete  pete  3 Jan  6 12:35 http:/

./http::
total 5
-rw-------  1 pete  pete  5 Jan  6 12:35 qwer

[pete@slow:~/tmp]
287>