## 3 Materials and Methods
### Framework Architecture
#### 3.3.4 File System and Server  
Some system functionalities, such as data persistence, storing static resources, and scripts, require a specific type of persistent memory for storage. The most common method of achieving this is by using formatted flash memory (via libraries such as LittleFS and SPIFFS) or external media (SD cards through the SD library) [1]. Two main routes are registered on the web server for uploading and executing user code from the file system. The first route, \"/stc/upload\", handles POST requests for file transfers, delegating the actual transfer process to the \"handleFileUpload\" function, and responds with a simple HTTP status 200 upon successful completion. This function interacts with the HTTP server to manage various stages of the file transfer: initiation, writing, and completion. When the transfer begins (status \"UPLOAD_FILE_START\"), the file name is checked to ensure it conforms to a specific length constraint (defined by the constant LFS_NAME_MAX from LittleFS, which is 32 characters). If the file name exceeds this limit, it is truncated to fit while retaining the \".stc\" extension. The file is then created and stored in the \"/programs\" directory on the flash memory. As data begin to be written (status \"UPLOAD_FILE_WRITE\"), the system writes the incoming data blocks to the newly created file. Finally, when the transfer ends (status \"UPLOAD_FILE_END\"), the file is closed, and the client is redirected to a URL that allows the resource location to be reviewed, signalling a successful upload. If an error occurs while creating the file, the server sends an HTTP 500 response with an error message to the client. The second route is dedicated to loading a file into the virtual machine and takes the file name as part of the URL (denoted by curly braces \(\{\}\) in the route). It opens the corresponding file from the LittleFS file system. If found, its content is loaded into a buffer and subsequently passed to the \"loadFunctionObject\" function, which performs deserialization of the bytecode into a FunctionObject. If the virtual machine is already running, it is reset to allow loading a new program. The \"initVM\" function initializes a new instance, and the function derived from the file is called and interpreted within the main loop. After loading, the server responds with a success message, closes the file, and deallocates the buffer. The custom \"FileAccessHandler\" class inherits the \"RequestHandler\" class and is responsible for handling HTTP requests directed to routes prefixed with \"/files\". This requires overriding the base implementation of the \"canHandle\" method, which exclusively checks for the equality of the URL and the defined route. In this case, it verifies if the requested URL starts with \"/files\", matches it exactly, or ends with a \"/\", implying that the request pertains to a file or directory within the \"/files\" prefix. The main component of the class is the \"handle\" method, which is triggered upon receiving a valid request. This method processes requests for files and directories, distinguishing between file delivery for download and listing directory contents in HTML format. If the request refers to a directory, the method opens the directory using the \"IfsOpenDir\" function and retrieves its contents with \"IfsLs\", which returns a linked list of \"DirEntry\" objects. Both functions are part of the binding layer, making them accessible for user code. If the request is for a file, the system checks for its existence by calling \"LittleFS.open\". If the file is found and is not a directory, its content is read into a dynamically allocated buffer and then served to the client as \"application/octet-stream\" content, suitable for downloads. After delivery, the allocated buffer memory is freed, ensuring efficient memory management in a resource-constrained environment. On the other hand, if the request pertains to a directory, the method dynamically generates an HTML page displaying the directory's contents.