[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