<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/doc/dev/notes/restricted-discovery-reloads.md, branch main</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=main</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=main'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2024-10-03T11:55:00Z</updated>
<entry>
<title>doc: Note that client authorization was renamed.</title>
<updated>2024-10-03T11:55:00Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2024-10-03T11:52:01Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=3f4116465a4929be515d82a848251078b1319079'/>
<id>urn:sha1:3f4116465a4929be515d82a848251078b1319079</id>
<content type='text'>
This adds a note mentioning the new "restricted discovery" terminology
to the various docs that talk about client authorization.
</content>
</entry>
<entry>
<title>dov/dev/notes: Add note about live reloads in restricted discovery mode.</title>
<updated>2024-08-12T12:04:31Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2024-08-06T17:33:41Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=c102cf7a2f5f9872a2052e1044494494e1375bd4'/>
<id>urn:sha1:c102cf7a2f5f9872a2052e1044494494e1375bd4</id>
<content type='text'>
This describes a couple of options for extending the config reloading
logic to support watching for changes in the
`restricted_disovery.key_dirs` directories.

Note: the options we have here are, in a sense, two extremes
  * one is about refactoring some of the existing code into a
    reusable component, and leaving most of the configuration logic
    unchanged
  * the other involves rethinking the entire config watching/reloading
    mechanism to support watching for changes in arbitrary directories

I am leaning towards the simpler option, because I'm not sure the other
one is worth the added complexity (we currently only have a single use
case for it).
</content>
</entry>
</feed>
