Repository navigation
ngclient: client-level constants #1402
Description
The constants could use some thought: We definitely don't want to keep using tuf.settings, but I guess the question is, should these be instance variables in Updater instead of module level ones:
MAX_ROOT_ROTATIONS = 32
MAX_DELEGATIONS = 32
DEFAULT_ROOT_MAX_LENGTH = 512000 # bytes
DEFAULT_TIMESTAMP_MAX_LENGTH = 16384 # bytes
DEFAULT_SNAPSHOT_MAX_LENGTH = 2000000 # bytes
DEFAULT_TARGETS_MAX_LENGTH = 5000000 # bytes
Maybe it does not hurt if they were instance variables instead. They don't even need to be optional constructor arguments (as initialization does not use any of them: caller can initialize the Updater and then modify the values).
I guess the fanciest option is that constructor takes an optional argument dataclass UpdaterOptions with those attributes ...
Originally posted by @jku in #1396 (comment)
Activity
[-]experimental client: client-level constants[/-][+]ngclient: client-level constants[/+]sechkova commentedon Jun 29, 2021
I am in favour of the dataclass option because it groups all the configuration at one place and I drafted a proposal based on it: #1470.
There is also
RequestsFetcherwhich needs to be configured on init so I added the configuration as an optional parameter toUpdater. However I am not totally sure if this solution makes it convenient enough to customise the configuration and I will be happy to hear some opinions about it.trishankatdatadog commentedon Jun 29, 2021
Me too 🙂