Feature - Implemented Cache copy of faxbot.xml
- Thread starter Fluxxdog
- Start date
Restarting Mafia doesnt refresh FaxBot
Due to crappy internet in China, Mafia encountered an issu when trying to build the faxBot's interface.
"Somethin, somethin .xml error"
When I try to go back into people-> Request a fax , it gives me "No FaxBot configured"
Tried to log off/on didnt change anything.
Is there a setting I need to delete in a file somewhere?
Due to crappy internet in China, Mafia encountered an issu when trying to build the faxBot's interface.
"Somethin, somethin .xml error"
When I try to go back into people-> Request a fax , it gives me "No FaxBot configured"
Tried to log off/on didnt change anything.
Is there a setting I need to delete in a file somewhere?
These threads seem to be worth merging.
I put together some code for this that works by writing data/faxbot.xml whenever it's read from the server (by converting the DOM back to a File...), and then reading that file when it can't be loaded from the server. Then I looked at Catch22's patch, which actually looks simpler than mine. I don't see how the result of
gets used, and that seems to be an important part of it being a useful patch...
Code:
connection.setIfModifiedSince( local.lastModified() );
Interesting. I don't see his patch. He says "This patch", but my browser is not showing me a patch.
I'd like to see both of your patches.
OK, I found his patch. I had to take him off my ignore list before looking at his message before it would show me the attachment.
He whacked downloadFile - but I whacked it even more severely when I souped up image caching.
Basically, he is always asking for the file from the remote server, but he's saying "send a not modified if it is not modified after the date I gave you" - the date being the modification date of the locally cached file. And since my (more recent than his patch) code sets the modification date to the date that came with the file, that's reasonable enough.
The result of the "setIfModifiedSince" is to add a If-Modified-Since header to the HTTP request, which will result in the remote server either sending a 200 and the file or a 304, which says "use what you have".
I think "smarterCache" is a bad name for the optional third parameter to downloadFile. I'd call it "probeLastModified" or something.
Let me see how I would integrate that into the current version of downloadFile.
He whacked downloadFile - but I whacked it even more severely when I souped up image caching.
Basically, he is always asking for the file from the remote server, but he's saying "send a not modified if it is not modified after the date I gave you" - the date being the modification date of the locally cached file. And since my (more recent than his patch) code sets the modification date to the date that came with the file, that's reasonable enough.
The result of the "setIfModifiedSince" is to add a If-Modified-Since header to the HTTP request, which will result in the remote server either sending a 200 and the file or a 304, which says "use what you have".
I think "smarterCache" is a bad name for the optional third parameter to downloadFile. I'd call it "probeLastModified" or something.
Let me see how I would integrate that into the current version of downloadFile.
Here's my patch. It has basically no overlap with his patch, and my approach seemed a bit silly to me even as I was writing it.