Re: [AD] Emscripten port: writing persistent files

[Max Savenkov <max.savenkov@xxxxxxxxxx>]

On further examination, I saw that things work a bit differently.
Actually, we won't need a full-blown FS interface for that persistent
storage. After we mount specified directory as IDBFS, we can freely
use usual fopen/fwrite etc. functions to work with it. But there are
two catches:

1) Mounting IDBFS is a asynchronous operation, and there is no way to
make in synchronous in C++ code (Well, actually, mounting IS
synchronous, but populating mounted folder from stored IndexedDB is
not, and until it is complete no read operations could be performed,
and I don't think allowing write operations in that time is a good
idea either).

2) IDBFS needs to be synced periodically (or after every write, or at
the end of work).

I can't hide mounting FS from user, because while I could probably
cache write operations into memory, I can do nothing with read
operations (other than to return error).

It seems that it is impossible to implement interaction with IDBFS in
such way that user will need little modification to his programs to
use it, so I guess there is no point in trying :( After all, it's
really easy to implement in your own cod, it's just hard to implement
this with Allegro's standard FS interface, which is synchronous. I'll
just document it in README file and let users handle it.

2014-05-18 18:35 GMT+04:00 Elias Pschernig <elias@xxxxxxxxxx>:
> On May 17, 2014 10:39 AM, "Max Savenkov" <max.savenkov@xxxxxxxxxx> wrote:
>>
>> By default, Emscripten provides implementation for various file and
>> filesystem-related functions which reads data from memory, using
>> embedded or preloaded packed filesystems. This allows programs to read
>> data as usual with fopen etc.
>>
>> However, if you WRITE any files, they are not really stored anywhere
>> and will be lost when page is reloaded. To avoid this, Emscripten
>> provides API to write to IndexedDB, which allows persistent storage of
>> files for web pages.
>>
>> To allow user to work with both in-memory and with IDB data, I think I
>> will need to write a file interface, like one for PhysFS, which will
>> user will have to set when he is working with persistent data. So, if
>> I want to load a resource, then save and load game state, the
>> pseudo-code would look like this:
>>
>> // Load resource from memory
>> load_resource( "res/res1.dat" );
>>
>> #ifdef EMSCRIPTEN
>> // Create and mount directory 'saves' (as per
>>
>> https://github.com/kripken/emscripten/blob/master/tests/fs/test_idbfs_sync.c
>> example)
>> al_ems_mount_idbfs( "saves/" );
>>
>> // Set IDBFS file interface
>> set_file_interface( al_ems_get_file_interface() );
>> #endif
>>
>> // Save file to IDBFS
>> write_save( "saves/save1.sav" );
>>
>> #ifdef EMSCRIPTEN
>> // Restore default file interface for further loading of resources etc.
>> set_file_interface( al_get_default_file_interface() );
>> #endif
>>
>> This will require programs that used just to write things anywhere to
>> be modified with ugly #ifdefs, but I can see no way to do this
>> transparently. So, unless anyone has a better idea, I will do it this
>> way.
>>
>
> Sounds good to me.
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers