Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #8050

Closed
Open
Opened Jan 24, 2013 by Karsten Loesing@karsten

Stem's DescriptorReader should provide an option to provide statuses vs. status entries

When I pass a tarball of consensuses to Stem's DescriptorReader, it gives me an iterator over status entries, though I'd expect an iterator over statuses. I see the advantages of returning status entries rather than waiting until a full status is parsed. But for most use cases I'm interested in, I want the status and then maybe look into status entries.

For example, I might want to extract supported consensus versions or bandwidth weights over time; no need to look into status entries for that. The alternative, to iterate over status entries and look at every referenced status document to see if I saw that before or not, seems complicated. It probably doesn't even work for bandwidth weights which are parsed after the status entries.

Can we have a parameter in DescriptorReader to specify whether it should provide top-level documents or subdocuments? I'd even argue that top-level documents should be the default, because the DescriptorReader will mostly be used for batch processing where latency and memory consumption are not an issue. But I can see how changing the default might make other people unhappy.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#8050