Re: [tor-bugs] #19842 [Metrics/metrics-lib]: offer a `LenientParser` option with metrics-lib

2017-05-12 Thread Tor Bug Tracker & Wiki
#19842: offer a `LenientParser` option with metrics-lib
-+
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  worksforme
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * status:  needs_information => closed
 * resolution:   => worksforme


Comment:

 It seems there is no need currently for the different type of parser.

 Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19842 [Metrics/metrics-lib]: offer a `LenientParser` option with metrics-lib

2017-05-08 Thread Tor Bug Tracker & Wiki
#19842: offer a `LenientParser` option with metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 Hmm, I don't know how to proceed with this issue.  A few thoughts:

  - We should only use new properties for new implementations of a parser
 or reader, not for a config option.  If we want a config option, let's add
 a method to the descriptor source.
  - `DescriptorReaderImpl` internally uses a `DescriptorParser` for parsing
 descriptor.  If we just want to switch to another parser, let's create a
 method `DescriptorReader#setDescriptorParser()`.  Or let's use
 `DescriptorSourceFactory` internally to create a parser instance rather
 than instantiating `DescriptorParserImpl` directly.
  - The case of non-ASCII characters in statistics lines seems rather
 special, and doesn't seem worth adding an option that 99.9% of users won't
 care about.  We could generalize and provide an option to not fail
 descriptor parsing if a single line cannot be parsed, or something like
 that.
  - If non-ASCII characters in statistics line are spec-conformant, let's
 fix metrics-lib by default.  I don't recall whether that's the case.  But
 if it's a spec violation, let's treat this case as any other spec
 violation.
  - How much do we still care about this issue?  Is there a current use
 case that would justify putting in the effort?  If yes, okay.  But if not,
 let's just close this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #19842 [Metrics/metrics-lib]: offer a `LenientParser` option with metrics-lib

2016-08-05 Thread Tor Bug Tracker & Wiki
#19842: offer a `LenientParser` option with metrics-lib
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Provide another parser option, quote from #19170#comment:7

   make use of the `descriptor.parser` and `descriptor.reader` properties
 and supply a different non-ascci-accepting parser, let's call it
 `LenientParser`, as well as a LenientReader.

 * Necessary change in CollecTor would be to set the `descriptor.parser`
 and `descriptor.reader` properties to the LenientParser class.
 * Necessary change in metrics-lib would be the addition of the
 LenientParser, which consist mostly in providing additional ParserHelper
 methods that accept non-ascii and calling these in the appropriate places;
 most of the code will be the same as in the current, stricter
 implementation.  Also a LenientReader would have to be supplied.

 That way we could switch between implementations.
 Users of metrics-lib would also have another option.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs