Actually, looking at the source, I see you are already using HTTP status
code for these kind of errors
(https://github.com/kripken/emscripten/blob/incoming/src/Fetch.js#L278) but
it looks like this is not propagated up to the final onsuccess callback.
It would be perfectly fine, for this case, to get onsuccess callback
called, but with http status code 413.
On Friday, March 10, 2017 at 10:08:24 AM UTC-5, Robert Goulet wrote:
>
> I meant "succeeded"... sorry for my bad english.
>
> On Friday, March 10, 2017 at 10:06:16 AM UTC-5, Robert Goulet wrote:
>>
>> Actually, perhaps we can do a bit more:
>>
>> What about replicating the attributes of the original fetch, but
>> separated in succeded/failed variables?
>>
>> struct emscripten_fetch_t {
>> ...
>> uint32_t attributesSucceded;
>> uint32_t attributesFailed;
>> };
>>
>> attributesSucceded would be assigned all the attribute flags that
>> succeeded, and attributesFailed the ones that failed. The reason for
>> this is sometimes we'd like to get back all the original attributes that
>> were used for the original fetch (attributesSucceded|attributesFailed),
>> or know exactly which ones succeeded (attributesSucceded) or which ones
>> failed (attributesFailed). I think this is more flexible and opens the
>> door for future flags that could also be combined in a single fetch.
>>
>> Think that is a good idea?
>>
>> Thanks
>>
>> On Thursday, March 9, 2017 at 5:56:23 PM UTC-5, jj wrote:
>>>
>>> That's a good point.
>>>
>>> It's not a bug that download works, xhr fails and the result is a call
>>> to the success handler. However I think we should improve the API to report
>>> in the success handler that only the download succeeded, but not the IDB
>>> store. Would it work if there was a some parameter in the fetch attribute
>>> structure to signal that?
>>>
>>> 2017-03-09 20:09 GMT+02:00 Robert Goulet <[email protected]>:
>>>
>>>> Hi,
>>>>
>>>> before I log a bug, just checking here if I did a mistake or if there's
>>>> a way to handle this case:
>>>>
>>>> When fetching files using both EMSCRIPTEN_FETCH_LOAD_TO_MEMORY
>>>> and EMSCRIPTEN_FETCH_PERSIST_FILE flags at once, it seems fetch will
>>>> execute onsuccess callback even if the persist file failed. This happens
>>>> when fetching a file too large to write in IndexedDB (which happens often
>>>> in Chrome, since apparently they set a limit on the file size allowed in
>>>> IndexedDB) while the XHR to memory was successful.
>>>>
>>>> Would that be considered a bug in emscripten fetch?
>>>> What can I do on my side to properly handle this?
>>>> Preferably we don't need to re-fetch every file
>>>> with EMSCRIPTEN_FETCH_NO_DOWNLOAD to verify if they were correctly written
>>>> to IndexedDB?
>>>>
>>>> Thanks!
>>>>
>>>> On Wednesday, March 8, 2017 at 8:41:04 AM UTC-5, jj wrote:
>>>>>
>>>>> 2017-02-24 12:31 GMT-08:00 Robert Goulet <[email protected]>:
>>>>>
>>>>>> However this pose the problem that if the content changed on the
>>>>>> remote, the local storage will be used instead of the newer remote
>>>>>> content.
>>>>>> I was hoping there would be a way to compare remote file timestamps with
>>>>>> local storage file timestamp, and replace local storage if remote file
>>>>>> timestamp is newer, but I couldn't find it.
>>>>>>
>>>>>
>>>>> This is a TODO I have, my thinking was that there could be an
>>>>> attribute flag EMSCRIPTEN_FETCH_DOWNLOAD_IF_NEWER that would still
>>>>> perform
>>>>> an XHR and get back a 304 Not Modified if the copy in IndexedDB was up to
>>>>> date. Iirc there was a discussion thread about this earlier on
>>>>> emscripten-discuss when the fetch API was being circulated for review. A
>>>>> second related request is to support content ETags, which is also on the
>>>>> radar.
>>>>>
>>>>>
>>>>>> Should I be implementing my own versioning system somehow? A
>>>>>> timestamp based system would have been nice because it would allow to
>>>>>> replace single files instead of all files. Should I look into
>>>>>> implementing
>>>>>> a timestamp replace option in Emscripten fetch API, or should this
>>>>>> entire
>>>>>> versioning system stay outside of the API?
>>>>>>
>>>>>
>>>>> Definitely if you have some kind of "higher level" understanding in
>>>>> game code to deduce which assets may need updating, that kind of
>>>>> versioning
>>>>> will always be superior in performance compared to a fine-grained
>>>>> timestamp
>>>>> based scheme at individual file level. This is because if your assets are
>>>>> mostly immutable/nonchanging and doing timestamps, each IndexedDB file
>>>>> read
>>>>> will still incur a XHR to remote server to get back that 304 Not
>>>>> Modified,
>>>>> which can be a lot of redundant pings if there are lots of files.
>>>>> Currently
>>>>> if a XHR is cached to IndexedDB, there are no XHRs performed at all to
>>>>> remotes when loading the file, which is very fast. Therefore if you have
>>>>> a
>>>>> higher level scheme that you can employ, it will always be more efficient
>>>>> than individual file level.
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
