For this release I have challenged myself to work with a back-end of the Thimble app. The issue talks about introducing project limiting feature to Thimble.
Thimble hosts all user projects on their servers. Since, the editor is designed as a learning tool for people who are trying to get into web programming, not all of the users understand implications of information transfer between client and sever. This leads to giant projects being created be users. Every time the project is loaded, it takes too much time to transmit all of the information, so browser times out. Not a really good user experience.
The solution is still in discussion, however some common ground has been achieved. The answer seems to be an introduction of stage-based system for tracking project size, this includes possible number of files and maximum size of a single file. There should be two stages of warnings:
- Stage one (soft warning) – once soft cap of project size is reached, a pop-up is supposed to appear to let user know that they are coming close to the maximum capacity of a single project.
- Stage two(error) – once hard cap of project size is exceeded, an error should come up, explaining the problem and the ways for solving it (e.g. using external hosting services).
Once again, the feature is not necessarily ready for the production version, so for now it will only be used for debugging purposes.
In my previous post about Release 0.2, I assumed the knowledge of my previous fix would help me here, too. I’ve never been so wrong in my life. Current task involved file handling and creation of a brand new module for Bramble. Both things I had no idea how to do. Likely, I had guidance from David Humphrey on where to start looking.
As it turns out, all of the file modification requests have to come though Bramble’s core in main.js. Some code tinkering enabled me to pinpoint exacts spots of file interactions. Bramble uses Filer project for managing its file structure. Here is a snippet:
The writeFile function modifies file with a new content. My job was to record the file size before and after the update and figure out if file was appended, deleted from or erased completely. After some thought and advice from David Humphrey, I decided to settle with checkLimits function that will record the changes of the project and return the new size of the project in a callback. Moreover, I noticed that genericFileEventFn function is called every time file is being modified, whether it is being updated or deleted, so the logical conclusion would be to put my checkLimits function call there. Here this is how it looks:
Finally, I just needed to figure out how to calculate file size change. Given and old size and pathname to the file, it is not really difficult. On the other hand, things are not as smooth when deleting whole file. Since my module works with the file tree post update, deleted file no longer exists. Given the circumstances, I have to catch the exception being thrown by the Filer and adjust project state accordingly. However, this approach produces a bug: consider the case when an invalid file name is passed. Filer produces the same error as when file is deleted, which could lead to incorrect behavior should oldSize variable be something else than 0. For now, this bug persists and it will be something for me to fix in the near future.
At the end of the day, my pull request is being reviewed as I am writing this blog post… Hopefully, they will read it after landing the PR. =)