REMOTE_REASON not supported for circuit failure about txtorcon

[lukaslueg]

why is this still open?

[meejah]

I was waffling on the API I really want to support for this, basically. Currently IStreamListener.stream_failed has a remote_reason argument; I'm thinking of changing this to just be a dict of any/all the flags passed from Tor but want to make sure that's a Good Idea so I don't have to change the API twice ;)

[meejah]

Do you think it's better to pass the additional flags as a single argument which is a dict, or as a **kwargs style thing? I'll push branch "issue-18" in a moment if anyone cares to comment.

[lukaslueg]

**kwargs was made for "single argument which is a dict of some parameters"

For example: This allows you to "upgrade" a specific flag to a full function keyword by simply changing foo(arg1, *_kwargs) to foo(arg1, arg2, *_kwargs)

[meejah]

...the advantage of using **kwargs would be that you could declare an implementation like:

def circuit_closed(self, circuit, remote_reason=None, reason=None)

...if you only care about two of the possible flags. Contrasted with:

def circuit_closed(self, circuit, flags):
if 'remote_reason' in flags:
pass

[lukaslueg]

It depends on wether or not you expect the signature of circuit_closed() to be stable and how important those flags are. If "remote_reason" is used all the time, I would consider it being a keyword to the function more intuitive:

def circuit_closed(self, circuit, remote_reason=None, **additional_flags):
if remote_reason == "smells":
if 'type_of_stink' in additional_flags:
...

[meejah]

"reason" is always present (for closed, failed circuits) and remote_reason "often" (only if the other Tor closed the connection). There are other flags, and the spec says they may add more whenever, so I would expect this list to keep growing (and, obviously, I don't want to change the API every time control-spec changes).

So, I will probably declare the methods with reason (and maybe remote_reason?) and leave the rest in **kwargs. Sorry I still haven't pushed the issue-18 branch, should get to that in the next couple hours.

[lukaslueg]

I'd consider circuit_closed(self, circuit, reason, **additional_flags) then

[meejah]

One other thought: I could save any flags from the last update as "stream.flags" and the interested event handlers can still easily access them. It's not 100% clear to me from the control-spec, but it seems that the correct state of the stream is reflected by the union of all received flags for events on the stream.