It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png
That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff.
I'm not a web developer at all. I'm just researching this as I type it.
Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.
The problem is that most people don't have a local server. Even if you have local (geographical nodes) your still limited to the clients bandwidth.
Also how can you load say models but not textures? All files are just binary data.
I guess your only option is to play around with indexDB. Also it that per file 50MB, or overall 50MB. I guess with more aggressive compression could could achieve decently small disk usage.
dont worry CORS or same origin policity have nothing to do with the way the server should load assets.Not sure why the other guy talked about that. The issue you raised still stands.
That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff.
I'm not a web developer at all. I'm just researching this as I type it.