Fantastic! This is great, thanks Sebastian! Few thoughts are...
Lets have separate methods for getting the server and extrainfo descriptor. Unless I'm missing something there's no reason for 'GETINFO status/fresh-relay-descs' to return both. Maybe...
Just picking 'desc' here to be consistent with the earlier methods. Don't really care much about the name. :P
Nitpick but we're pretty inconsistent with descriptor naming...
'GETINFO desc/*' and Stem call the main self-published descriptors 'server descriptors'.
The dir-spec calls them 'router descriptors'... usually. It opts for 'server descriptor' in section 6.2.
CollecTor calls them 'relay descriptors'.
It looks like you're opting for 'relay descriptors' here. That's fine, just pointing out that we're inconsistent. Maybe we should have another ticket to settle on a name? The specs and CollecTor can easily change, but Stem's classes would be a problem since we vend those.
+ DOC("status/fresh-relay-descs",+ "A fresh relay/ei descriptor pair for Tor's current state. Not stored."),
I'm guessing the "/ei" is a typo?
if (router_build_fresh_descriptor(&r, &e) < 0) {
I don't know Tor's conventions but maybe != 0 is safer? In practice I know this is fine (presently it only returns negative or zero statuses) but not sure if this is like exit status codes where any non-zero indicates failure.
+ if (e) {+ size += e->cache_info.signed_descriptor_len + 1;+ }
Do you know the use cases where a server descriptor can be generated but an extrainfo can't? Didn't know that was possible.
Lets have separate methods for getting the server and extrainfo descriptor. Unless I'm missing something there's no reason for 'GETINFO status/fresh-relay-descs' to return both. Maybe...
Just picking 'desc' here to be consistent with the earlier methods. Don't really care much about the name. :P
I thought this too at first, but it's not possible to use this because the descriptors are temporary. To generate the relay descriptor, we have to generate the extra-info document too (to reference it from the descriptor). I could be convinced to add a method to just fetch the descriptor without extrainfo.
Nitpick but we're pretty inconsistent with descriptor naming...
'GETINFO desc/*' and Stem call the main self-published descriptors 'server descriptors'.
The dir-spec calls them 'router descriptors'... usually. It opts for 'server descriptor' in section 6.2.
CollecTor calls them 'relay descriptors'.
It looks like you're opting for 'relay descriptors' here. That's fine, just pointing out that we're inconsistent. Maybe we should have another ticket to settle on a name? The specs and CollecTor can easily change, but Stem's classes would be a problem since we vend those.
I think this is for another ticket, another time
{{{
DOC("status/fresh-relay-descs",
"A fresh relay/ei descriptor pair for Tor's current state. Not stored."),
}}}
I'm guessing the "/ei" is a typo?
No, but extrainfo should be spelled out
{{{
if (router_build_fresh_descriptor(&r, &e) < 0) {
}}}
I don't know Tor's conventions but maybe != 0 is safer? In practice I know this is fine (presently it only returns negative or zero statuses) but not sure if this is like exit status codes where any non-zero indicates failure.
Imo that's fine.
{{{
if (e) {
size += e->cache_info.signed_descriptor_len + 1;
}
}}}
Do you know the use cases where a server descriptor can be generated but an extrainfo can't? Didn't know that was possible.
There's a code path. I don't know if there's any kind of way to trigger it in practice in current Tor. I don't think it is possible, but it's currently allowed.