> After looking at possible use cases, wouldn't it make sense to allow the
> caller to specify a file to be written to?
Make sense, though via a convenience method. Libraries should provide
basic building blocks (such as 'give me the csv string for these
descriptors') in addition to less flexible
Hi Damian,
After looking at possible use cases, wouldn't it make sense to allow the
caller to specify a file to be written to? Regardless, we were thinking of
creating two methods, one that takes a list of descriptors, and one that
takes a single descriptor. This would remove the need to check fo
On Mon, Jul 9, 2012 at 8:40 AM, Erik I Islo wrote:
> Hello,
>
> Megan and I have been working on the CSV export functionality that was being
> discussed a little over a week ago, and given the recent discussion, we
> would like to clarify the expected/desired implementation of this feature.
>
> We
Hello,
Megan and I have been working on the CSV export functionality that was
being discussed a little over a week ago, and given the recent discussion,
we would like to clarify the expected/desired implementation of this
feature.
We have created an export.py module within /stem/descriptor, which
> 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
Yes, I was wondering whether there would be something simpler than
Django after I wrote that message.
Megan and Erik: take a look through the websites for Django, Tornado,
and Cyclone/Twisted to get a sense as to what each does.
- Norman
On 7/6/12 10:34 AM, Sathyanarayanan Gunasekar
> OK; Megan and Erik, after you incorporate the export function into
> Descriptor in stem, please start reading through the Django tutorial.
I'm not sure if Django is a good choice for this project. We don't
require such a heavy web framework with a templating engine, auth,
etc. I'd rather use Tor
On 7/6/12 4:10 AM, Karsten Loesing wrote:
On Fri, Jul 6, 2012 at 4:25 AM, Norman Danner wrote:
Do I understand Onionoo correctly to be basically a small webservice that
returns a JSON formatted description of data read from a file based on the
HTTP request parameters, along with a program that
On Fri, Jul 6, 2012 at 4:25 AM, Norman Danner wrote:
> Do I understand Onionoo correctly to be basically a small webservice that
> returns a JSON formatted description of data read from a file based on the
> HTTP request parameters, along with a program that presumably runs with some
> frequency t
OK, bringing back to tor-dev...
On 7/5/12 1:44 PM, Damian Johnson wrote:
Hi Norman.
(Taking this off tor-dev@ for the moment until we get things straightened
out...)
Actually, this would have been an interesting discussion for the list.
Feel free to add it back in.
The TorExport functiona
>> Which descriptor parsers are you referring to, as some are already
>> implemented? A lot of what we're working on in Tor Export overlaps your work
>> regarding descriptor parsers.
>
> According to my proposal, I was to implement the parsers for V3
> network status documents and microdescriptor d
On Mon, Jul 2, 2012 at 9:24 PM, Megan Chang wrote:
> Which descriptor parsers are you referring to, as some are already
> implemented? A lot of what we're working on in Tor Export overlaps your work
> regarding descriptor parsers.
According to my proposal, I was to implement the parsers for V3
net
12 matches
Mail list logo