So.. this week I focused more on building the file caching mechanism that fully uses the server’s back-end. I am using a write-back approach to handle the caching process. Initially, a fresh copy of the project will be downloaded and stored in local cache. The file will be sent to another back-end and will be open for edit. Changes in the CodeMirror editor or the synthesis completion will both initiate a request (using back-end) and sends the latest file to the local cache.
As to sync-ing the project with storage (write-back), there are a few approaches:
- When user opens the project for edit.
The locally-cached project will be uploaded whenever user decides to open it, which can be easily implemented.
- When user closes the project after edit.
The project will be uploaded whenever user decides to close the project. This relies on using AJAX requests, which were proven to be quite unreliable in previous tests.
- During session timeout.
This has yet to be tested but it is by far the best approach in theory, since user inactivity/exit will result in a session timeout and this is the best time to sync it with cloud storage so that a reliable copy of the project is stored.
Using the Url format
During the file-caching requests, I had to include certain information in the query string. As there were several parameters, the request becomes quite messy. My boss then tells me to send it as one parameter in a URL format (actually he told me months ago, I just didn’t have the capacity to understand it). It actually works brilliantly.
A URL syntax can be referred as follows:-
scheme, user, password, etc. can be replaced with parameters instead. Then, using a URL parser in Wt (Wt::Http::Client::parseUrl()), then query parameter can be parsed easily and converts it into Wt::Http::Client::URL format. Therefore, it follows the format of:-
I can really appreciate the ingenious (at least for me) use of URL format to send query parameters. It is more concise and consistency can be achieved easily by setting a standard format.