Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

diagram application state machine #1452

Closed
cfm opened this issue Mar 28, 2022 · 4 comments
Closed

diagram application state machine #1452

cfm opened this issue Mar 28, 2022 · 4 comments
Assignees

Comments

@cfm
Copy link
Member

cfm commented Mar 28, 2022

Description

In #1420 (comment), we decided to

take this bug as our cue [...] to zoom out, define carefully how we expect the application to behave across these state machines, and then return to code-level work from that understanding.

This line of investigation has resulted in https://gist.github.com/cfm/4f9f84651312ec446b3a380b1772259a, a draft "grand unified state machine" for the operation of the SecureDrop Client. While this draft is both (a) incomplete and (b) aspirational, there's broad consensus on the team that a future version of this diagram this will be a useful addition to the Client's architectural documentation. This ticket tracks the development, revision, and acceptance of this diagram.

User Stories

As a developer, I want to be able to use a canonical visual aid to reason about [changes to] the low-level behavior of the SecureDrop Client.

@sssoleileraaa
Copy link
Contributor

As a developer, I want to be able to use a canonical visual aid to reason about [changes to] the low-level behavior of the SecureDrop Client.

Thanks, Cory! Onboarding new engineers has made this user story very clear to me. Once we get a good visual representation of what's actually happening in the client, whether it's before or after #1420 is resolved, I think we should add it the architecture wiki page (note that the workstation docs does not include a developer section): https://github.com/freedomofpress/securedrop-client/wiki/Architecture, and consider this issue resolved. What do you think?

@cfm
Copy link
Member Author

cfm commented Apr 13, 2022

Goal for this sprint: Accomplish @creviera's suggestion in #1452 (comment) and use that to decide on more-conclusive next steps on #1420.

@cfm
Copy link
Member Author

cfm commented Apr 27, 2022

My draft so far is able to (aim to) be grand and unified only by being a prescriptive monolith. @gonzalo-bulnes and I concluded yesterday that the reasonable way to approach this task descriptively is to diagram the current implementation at the level of individual components (e.g., RunnableQueueApiJobQueueController). I'm going to post drafts to the wiki by the end of today to wrap this up in the spirit of a time-boxed !ship.

@cfm
Copy link
Member Author

cfm commented Apr 28, 2022

Time-box results:

The RunnableQueue/ApiJobQueue state machine is documented in https://github.com/freedomofpress/securedrop-client/wiki/Architecture#queue-architecture. Feedback welcome!

As I sort of expected, the implicit Controller-level state machines—such as those handling authentication, synchronization, and the results of individual jobs—are individually too simple to be much illuminated by descriptive diagramming. It's in their interactions that these implicit state machines become complicated and hard to reason about. (Thus, alas, the monolithic-prescriptive approach.)

What is illuminating, as I discovered in #1454, are call/caller graphs. I'll have a pull request in tomorrow to add a make docs target that uses Doxygen to generate browseable documentation, including call/caller graphs, from the securedrop_client package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants