-
Notifications
You must be signed in to change notification settings - Fork 5
breaking up SDExport #33
Comments
here's a wip with a sketch of how things could be structured: https://github.com/freedomofpress/securedrop-export/tree/spike-reorg one difference from the above comment is that I was chatting with @creviera just now and she raised potentially breaking up the export and check actions further. I think this is a good idea because exports need a submission object (of type UML diagram after: |
This would be a huge improvement. A couple thoughts:
I think it would be great if we could combine this check and have just one error
This is a nitpick but I think it would be clearer if we went with:
Since our plan is to include a printer preflight check the same way we do for transferring files to disk. I will spend more time looking at the concept code in a followup review. |
This is related to #15 and contains some thoughts on how we might restructure the code in this repo. Note that these are just opinions, we should discuss before doing a big refactor.
First for reference here's a UML diagram of the existing code as of Nov 26:
We can notice from the UML diagram that each instance of the
SDExport
class is only ever going to use a subset of the defined methods, i.e. an USB export wouldn't ever use any print-related methods. It's also quite a large class and is doing a lot of different things so imho this is the best class to break up further. This is perfectly natural: originally this was small - and then we added print - and in the future we'll probably add even more export methods.Here’s one approach for restructuring: instead of each export involving a single
SDExport
object, each export would involve two objects:For the action, we'd create an abstract base class e.g.
ExportAction
which defines the interface that any export actions should implement. Even an interface as minimal asExportAction.run
I think would be beneficial for organization purposes. With that our main would look something like:The classes that implement the
ExportAction
base class could have the following hierarchy:They'd keep on their classes anything relevant specifically to that action at hand, e.g. for Print* objects they’ll have the
print_all_files()
and thesetup_printer()
methods.Two other smaller things that would be good to do as part of this is:
_
.SDExport
utility functions: I’m specifically thinking of bothsafe_check_call
andpopup_message
which we could make module-level functions.The text was updated successfully, but these errors were encountered: