Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #8050

Closed
Open
Created 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
Time tracking