Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

On Sat, Feb 9, 2013 at 11:27 PM, Damian Johnson <atagar@xxxxxxxxxxxxxx> wrote:
>> I wonder if we should avoid restricting connection types in the spec by
>> defining this argument as connection type _string_ as opposed to an
>> enumeration.
>
> That depends on how volatile you think it'll be. If it's reasonably
> static then an enumeration would probably be best.

I don't know.  I think it's somewhat more likely that we'll want to
add more connection types than sticking with these three.  Changed to
a string to be more flexible.

>> Has the advantage that we don't have to touch the spec whenever
>> we add another connection type.  Does that make sense?
>
> True, but that also means that event recipients have no idea what kind
> of values to expect or what they mean.

Right.  Still, I think using a string is better here.

>> A fine question.  Here are two examples of this event:
>> ...
>
> Ah, I see. That does make it trickier.
>
> I'm not spotting any precedent for doing multiple sub-mappings in an
> event. Doing this in positional arguments is simple to parse, but
> beside the lack of flexibility mentioned earlier it's pretty hard to
> read.
>
> I cringe a bit to suggest it, but maybe a mapping in a mapping?
>
> CELL_STATS PCircID=8 PConnID=47110 PAdded=created:1,relay:1
> PRemoved=created:1,relay:1

Looks fine.

>> Sure, sounds doable.  Will fix that.
>
> Thanks!
>
>> Want to suggest new event
>> formats with keyword arguments to make them easier to parse by Stem and
>> friends?
>
> Positional arguments aren't harder to parse, just harder to read and
> more inflexible. I'd be happy to suggest spec alternatives if you
> want. Mind if we revise the proposal based on the above first?

Sure.  Please find the revised proposal in branch proposal218 of my
public torspec repository:

https://gitweb.torproject.org/user/karsten/torspec.git/shortlog/refs/heads/proposal218

Thanks,
Karsten
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev