Changes between Initial Version and Version 1 of Ticket #29209, comment 3


Ignore:
Timestamp:
Apr 10, 2019, 1:52:25 PM (5 months ago)
Author:
asn
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #29209, comment 3

    initial v1  
    88This took much longer than anticipated because I first experimented with encapsulating others parts of `crypt_path_t` before deciding to go with `crypto`. In particular, I first started hiding `deliver_window` and `package_window` but I quickly realized that this would cause lots of conflicts with #26288. I think after #26288 gets merged, these two fields might be the next candidates for hiding.
    99
    10 Now in terms of general notes, this project took me more than 3 days of careful refactoring work, and I've only hided like 10% of the cpath structure. Hiding the whole structure is far far away since there are quite complicated structures involved like `extend_info_t`.
     10Now in terms of general notes, this project took me more than 3 points of careful refactoring work, and I've only hided like 10% of the cpath structure. Hiding the whole structure is far far away since there are quite complicated structures involved like `extend_info_t`.
    1111
    1212In terms of future goals here, I think hiding `extend_info_t` into its own interface would be quite convenient since that structure is used and poked in weird ways all over the codebase. Furthermore, that would mean we can eventually encapsulate `crypt_path_t` even better. Other plausible medium-term targets would be structures like `tor_cert_t` which are mostly hidden, but not completely.
    1313
    1414I also added some TODO notes in the top of `crypt_path.c` with more cpath-specific things we can move without too much trouble.
     15
     16Finally, I also tried to find any static analysis tools that will automatically output widely-used structures, or structures that could be hidden easily, but I didn't manage to find such a project for C.