[tor-dev] Stem Descriptor Parsers

[Damian Johnson]

> So is export intended to be an instance method of descriptor, one that just dumps a single csv line of the instance attributes (maybe subject to some selection of those attributes)?  Or a static method that takes a collection?

Either would work fine. I was envisioning the former, though on
reflection stem/descriptor/export.py module would probably be better
since that localizes this functionality and allows for better
expansion in the future (other formats such as json, or the inclusion
of import functionality).

> It seems like it might be awkward to have to hack stem itself to add a new export format (for example).  Is this a concern?

That depends on how useful users would find it to be. If researchers
commonly want csv export functionality then we might as well support
it. However, if it's a rarely desired feature then there's little
reason to clutter our API. My understanding is that this feature is
mostly for researchers and sysadmins, so as part of the target
audience I'm happy to defer to you on how we handle this.

> Do all the known use-cases make need both an interface to Tor Control and a descriptor utility library?

No, you're completely right. Stem's controller functionality utilizes
its descriptor functionality but not vice versa. Another design that
we could go with is to make several smaller libraries (descriptors,
controller, response parsing, shared utilities, etc) if stem grows
unwieldy. However, we're nowhere near that yet and keeping stem as a
single library makes development, testing, installation and usage far
easier.

Stem is a library to make working with Tor easier for developers and
researchers, with the current scope of the Tor control and dir specs.
My plan is to complete that, release it to the community, then see
based on feedback where we should go from there.