There is nothing much to be said for this week, but I’ll try my best as I can. Basically time for this week was spent addressing minor UI issues in my project. One of it was making my carousel component to be a bit more generic, so that it could hold not only the projects themselves, but also the project templates. This could be done through Slots in Vuejs. Basically, with slots, you could pass in anything into your component, in which different elements will be rendered depending on what is passed. Here is an example:
This is a message.
In my MyComponent.vue file:
Other than that, I added character limits to the input fields when a user edits a project’s title or description or the custom name for their boards. Without having such a limit, the user could conveniently input as many characters as he or she wants to the point where unintended consequences could happen in the UI. Furthermore, when updating a project’s meta data like its title and description, their new values would be encoded in a JSON payload so that it could be send to the server’s endpoint and save the new values into the database. Therefore, the payload should not be too big as a result of encoding large amounts of text data, saving some network bandwidth, and we also want to prevent large amounts of text data to be saved into the database, which may cause problems that we would want to avoid. At the moment, I give a reasonable character limit to each of the input fields, but it could be changed anytime.
Another part of the application, where users could potentially make mistakes, is when configuring a new storage to use in the application. It is very likely that the user could give incorrect details, therefore an error message should be shown informing them of their mistakes. However, another potential point of failure is when attempting to connect to their storage service. Since the connection is done over the network, there is some tendency for failures, like failure in the middle of transmitting network packets from source to destination, or the request has reached the destination but the service failed to respond. The usual mitigation procedure is to have a connection timeout, where a maximum number of seconds is given before aborting the request, and also to have some number of connection attempts, i.e retry the connection for this amount of times for each subsequently failure, but stop when the limit has reached. SSHFS has options to configure the connection timeout and the number of connection attempts. I defined their values as a constant and put it in a header file. The amount specified should be reasonable enough such that user does not have to wait too long before receiving a response from the server.
Other things I have done include giving more specific error messages in the UI and also some code refactorings on the front end and back end. House keeping stuff basically. That is all for this week unfortunately. I am aware that there are still things that need to be done for the P3 project, such as supporting other cloud storage services than just SSHFS, but I think Dr Shawn wants me to do another important project, as I have been working on this for about 6 months already. Hopefully, next week I have some direction to go to, as at the moment I’m unsure of what else can be done in my current project. We’ll see about it next week.