Move texpack directory back under IndexedDB mount point.

[rdebath]

I use a symlink to mirror the /texpacks/default.zip file into /classicube/texpacks/default.zip with care not to overwrite the user's choice to upload a new default.zip file.

The embedded preload file is stored in /texpacks and then I symlink it onto the IndexDB mountpoint. However, the symlink does not survive a reload intact so we must refresh it. Also if the user uploads their own "default.zip" the upload routine is set to delete the symlink and so we shouldn't delete that.

By default only a linkfile is stored on in the IndexDB so it's small and an update of the "cc.data" will update the default textures.

This seem to be #809.

I'm not certain about the choice to honour the user's choice to upload "default.zip", it might be better just to overwrite every time in which case it gets a little simpler.

[UnknownShadow200]

I intentionally only keep texture packs in memory. As oherwise when IndexedDB is preloaded, all texture packs get loaded into memory, wastefully increasing the webclient's memory usage. (Ideally I need to replace filesystem with custom implementation that loads certain files only on demand, but at very least have option to delete them)

[rdebath]

The default texture file is NOT stored in the IndexDB nor are the texture files downloaded for maps (by this change). Only files directly uploaded by the user. Most of these files are pretty small so they're not a serious problem. The very few remaining will necessarily be linked to a map with custom blocks and so are in a real sense part of the map and IMO should be stored in the same place. Note that a user will probably have saved multiple copies of this map too.

If I want to delete files for this site the obvious thing to do is to "clear cookies" (etc) which gets rid of everything and is the default "fix" that users will do. But in addition there is a selective delete in the developer tools (Application/storage/IndexDB).

However, you have just highlighted that the texturecache directory is stored in the IndexDB, this seems like much more of a problem as it's filled without direct user knowledge. While the config file ( "acceptedurls.txt" ) should be stored there, the additional cache seems like a bad idea.

The distinct issue that you want to have IndexDB file-system access done OnDemand doesn't look like a ClassiCube problem though. It's more of a feature request against Emscripten. One I don't see them doing as they'd first have to setup some sort of co-routine infrastructure to allow the open(2) system call to be blocked. They seem to much prefer providing an event driven EM_ASM based substitute.

[UnknownShadow200]

With keeping texture packs in memory, I'm referring to just the ones the user uploads

You are quite right in that texturecache is a far greater offender. Unfortunately it is necessary because

1. The http backend only downloads one thing at a time, so a slow skin would prevent loading texture pack from browser cache (working on fixing that gradually)
2. The browser might not even return the cached version it has (Dropbox has max-age of 1 minute if I recall)

Both these issues are problematic, as having a second or two where wrong texture pack might get shown is unacceptable

It would be a completely custom OpenAsync function or something like that, not expecting emscripten to change open or anything

[rdebath]

I've re-read this thread and well, I think we've fallen in a trap. And if we have the users will too.

The IndexDB storage is described as "permanent", we have forgotten that they don't mean the full unrestricted meaning of that word. They what they actually mean is "permanently cached". The word "permanent" is only referring to a timespan, the browser will still delete this if it "needs to".

This means that the ability to save multiple maps "in the browser" really should not exist because it's not actually "saving" the map it's more like taking a vm-snapshot or marking a point in an undo buffer.

Likewise the upload and download are not communicating with a server and the data hasn't been "uploaded" to the server's disk where it'll be carefully backed up by a sysadmin.

The upload and download are more like the correct analogues to load and save.

Further, the primary use of a local texture pack is for a local map (but, a server that uses only the default tiles is okay too) so it appears there should be one saved in the web client to match the single "cached" map. Not multiple ones like I've allowed for.

The texturecache is actually the correct usage of IndexDB though, yes, it needs a clear function.

I would say that it's a bad idea to encourage more data to be stored in-browser where it may be deleted at any time. So as emscripten assert the async IndexDB fetch/store is not wanted.

Based on this I think the changes needed are:

• Change texture page upload so you can only upload (and keep) the file "custom.zip" or choose between that and "default.zip".
• Warn about in-browser storage, place a note that the browser will delete games saved in the browser.
• Possibly rename the game "save" button, so it doesn't look as safe. Maybe "copy" ? "snapshot" ?
• Default the save name to the last used. That is, encourage only one copy in-browser and allow the browser to do it's "(123)" trick on download.
• Don't automatically close the save menu on in-browser save, only after a download.

Also possibly...

• The last map saved in-browser should be loaded by default (if in extended mode).
• Add buttons to upload/download the options.txt file and maybe acceptedurls.txt.
• Add option to delete everything in-browser except options.txt.
• Maybe, limit the number of in-browser saves allowed (one page?)

NOT wanted

• Selective delete of things -- would encourage keeping multiple of them.

The aim becomes to set the expectation that the in-browser save is not safe to use, so it won't be used as much and the size of IndexDB will get reduced organically.