On Sat, Feb 9, 2013 at 11:27 PM, Damian Johnson <[email protected]> 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
