Skip to content

Client architecture sync 2018 12 04

Erik Moeller edited this page Dec 5, 2018 · 1 revision

SecureDrop Client Architecture Discussion - December 4, 2018

Participants: Jen, Heartsucker, Jaysinh, Josh, Erik

Problems:

  • Duplicate downloads -> how to prevent in an elegant manner? User clicks on file, then clicks it again -- currently this will initiate two downloads. Hacky solve would be to disable UI. Useful: keep track of what's being downloaded [needs issue]

  • Use of tons of callbacks modifying state everywhere, leading to confusing/complicated application logic

  • We are explicitly running e.g. update_conversation_view to refresh the UI when the underlying state changes

  • What other problems do we have?

  • non-persistent model (qt) (during application runtime)

    • data store used for e.g. ConversationView should be the underlying database object, not a new dict
  • non-persistent widgets (during applications runtime)

    • We are deleting and recreating widgets to update the UI and losing data

Represent data in a http://pyqt.sourceforge.net/Docs/PyQt4/qabstractitemmodel.html and use delegates for display? See also: https://files.meetup.com/2179791/pyqt-model-view-framework-overview.pdf

Instead of elsewhere in the app using the DB objects directly, we'd just use them in the abstract model

Check out Calibre as a project that uses this approach: https://github.com/kovidgoyal/calibre/tree/master/src

To learn about Qt Model View programming: https://doc.qt.io/qt-5/model-view-programming.html

Refactoring application to use MVC may be precondition for larger changes such as use of QAbstractItemModel [needs issue] Potentially pause reply work for now, take on in current sprint -> Start with conversation view, go from there? -> Jen will coordinate

A modest proposal:

-> Wait until we've done MVC refactor?

Another point of discussion:

  • How to manage operations that have been optimistically completed on the client (e.g., "mark as unread") but may still be pending on the server (and may eventually error out)
  • The relevant actor should update the state locally upon failure, the UI should then update to represent this state

Existing actor libraries:

-> May need investigatory spike

Clone this wiki locally