[tor-bugs] #22141 [Metrics/metrics-lib]: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jun 14 10:58:11 UTC 2017
#22141: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
---------------------------------+-----------------------------------
Reporter: karsten | Owner: karsten
Type: enhancement | Status: needs_review
Priority: Medium | Milestone: metrics-lib 1.9.0
Component: Metrics/metrics-lib | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------+-----------------------------------
Comment (by iwakeh):
Replying to [comment:16 karsten]:
> `DescriptorIndexCollector` indeed does not parse any descriptors, and
neither did `DescriptorCollectorImpl`. But I didn't refer to
`DescriptorParseException` here. We wouldn't be able to include other
exceptions than `DescriptorParseException`, like `IOException`, in an
output by `DescriptorIndexCollector`, because there's no output. And that
was the plan for `DescriptorReader`, where we were planning to include
IOException in a returned `InvalidDescriptor`. (The code may make this
more obvious.)
Hmm, maybe I forgot about something, but IOE rather belongs to a file than
to a descriptor unless the two coincide.
>
> I also now understand your "ParseExceptionsLog" idea better. Basically,
we would create a new structure for logging that is less dependent on
classes and more related to operation. Not opposed to that idea. I could
imagine that we'd want to look more at the other log statements and see
what other channels would be useful. How about we leave that for after
2.0.0 is released?
Yes, that's fine or later.
>
> Can you look at the branch? I think it makes sense to look now.
Thanks!
I think UnparseableDescriptor should extend Descriptor otherwise there is
no access to the raw bytes etc. from the API.
* getDescriptorFile, getRawDescriptorBytes: should work in Un.Desc. as in
other Descr.
* getAnnotations, getUnrecognizedLines: This behavior needs to be defined
and documented in small tests. (Annotations might be corrupt,
unrecognized lines might not be identifiable etc.)
Other than these this looks ok as a 1.9.0 release solution.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22141#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list