Ideas for how to tackle the ReadWrite class (and files in general)

[nidunc]

Currently we have the ReadWrite class, which contains the following functions.

• hasShareableFiles: Currently checks whether there are any files in the main files directory; no distinction between the type of files or possible subfolders.
• getShareableFiles: Returns all files (their names and contents) that are present in the main files directory; irrespective the types of files.
• removeShareableFiles: Removes every single file in files; no option to choose a particular file (which may not be necessary anyway).
• writeFiles: Writes files (with a given [path+]filename and contents). Currently checks whether the path given is a relative path or an absolute path; if absolute, the path is used as-is, and if relative, the path is added to the main files directory’s path.
  (In my local repository, I have added some code that checks whether absolute paths are relative to the files directory, ensuring that the program refuses to / is not able to write anywhere outside of its directory.)

So far, we’ve only been handling simple text files, for which the current code (mostly) sufficed. However, the program is starting to become more complicated, as file encryption/decryption and pdf creation code is being added.
This means the following:

1. It’s not handy to put all files in the same directory anymore.
2. Logic has to be added to ReadWrite to handle different types of files.

Below are suggestions/ideas for both points.

1. Two ideas for a new directory structure

The file names are just examples/suggestions.
And I am personally in favour of the first example, but the second option is of course also still possible (as are any other options I may not have thought of yet).

1. [main code directory] ├── files | ├── pdf | | | [pdf files, starting with {file_prefix}, followed by a digit, and ending with .pdf. | | | Examples below:] | | ├── file_1.pdf | | ├── file_2.pdf | | └── file_3.pdf | ├── salt | | | [text files, starting with {file_prefix}, followed by a digit | | | (to match the corresponding text file), then by _salt, and ending with .txt. | | | Examples below:] | | ├── file_1_salt.txt | | ├── file_2_salt.txt | | └── file_3_salt.txt | └── txt | | [text files, starting with {file_prefix}, followed by a digit, and ending with .txt. | | Examples below:] | ├── file_1.txt | ├── file_2.txt | └── file_3.txt └── [all other folders and files]
2. [main code directory] ├── pdf_files | ├── file_1.pdf | ├── file_2.pdf | └── file_3.pdf ├── salt_files | ├── file_1_salt.txt | ├── file_2_salt.txt | └── file_3_salt.txt ├── txt_files | ├── file_1.txt | ├── file_2.txt | └── file_3.txt └── [all other folders and files]

2. Ideas for rewriting the ReadWrite class

1. Making the directory a parameter, and creating three instances of the ReadWrite class (one for each type of file) here instead of just one.
2. Keeping everything in one file, with just one class, and let the functions themselves handle the different types of files (adding new functions wherever necessary).
   • hasShareableFiles
     1. Add a type parameter, accepting the following: pdf, salt, text.
        The function would use match (or a combination of if/elif/else) to determine which directory to check, depending on which type was specified.
        • It could also accept all, which would return true if there is any file present in files (and/or in any subdirectory), regardless of its type (which is how it currently works), or it could just default to that behaviour when no type has been specified—but this functionality may not even be necessary.
     2. Or add a directory parameter (accepting pdf/salt/txt subfolders of files, or pdf_files/salt_files/txt_files ‘main’ directories). Very similar to a type parameter, but simpler, as no logic is needed to find a directory for a given type anymore. (To be honest, I still prefer a type parameter.)
   • getShareableFiles
     • Same as hasShareableFiles, basically (the only difference being that getShareableFiles returns the files that were found, and not simply a boolean indicating whether any files were present).
   • removeShareableFiles
     • Same; deleting files of the specified type / in the specified directory instead of returning a boolean or the files themselves.
   • writeFiles
     • For handling different types of files:
     • Either add a type/directory parameter, or
     • Determine the type of file (and where to place it) based on the filename specified.
       This would mean no extra parameter has to be added, but the filenames will have to be consistent and follow a set pattern.
       • For .pdf files, simply looking at the extension would be enough.
       • For .txt files, check if the filename contains salt (for example) or not to determine whether it’s a text or salt file.
   • Possible extra class: getFile, to get the contents of a single file.

This section (and this issue as a whole) is not necessarily finished yet, but I’m posting it anyway, to give my own thoughts on all this and gather the ideas of everyone else.

[mhoek2]

Im also favor of the first suggestion in for the new directory structure.

I agree, getShareableFiles and hasShareableFiles can be merged into a single method.

Regarding the parameter change of hasShareableFiles, Id like to suggest something along these lines:

def hasFiles( self, directory ) -> list:
   ...

def hasTextFiles( self ) -> list:
    return self.hasFiles( self, self.settings.txt_filedir )

def hasPDFFiles( self ) -> list:
    return self.hasFiles( self, self.settings.pdf_filedir )

As for a seperate subdirectory for salt_files seems to add unneccesairy complexity imo. The requirements state that all salts/passwords are contained in a single file called password.secret. I propose to keep it in the same folder as txt files, so we can use one for loop to send over all relevant files required to encrypt and decrypt.

[mhoek2]

@nidunc

I couldn't help myself but but try write a quick mockup of my idea using wrapper functions. https://github.com/mhoek2/tcp-share/tree/read-write-wrapper-function-idea

Please have a look :)