[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2841 [Pluggable transport]: Implementing the pluggable-transport spec
#2841: Implementing the pluggable-transport spec
---------------------------------+------------------------------------------
Reporter: asn | Owner: asn
Type: task | Status: new
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Pluggable transport | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by nickm):
quick notes:
All new functions types and fields will need documentation. Remember to
"make check-spaces", and to configure with --enable-gcc-warnings .
bridge_add_from_config() should document that the bridge now owns the
transport_protocol_t, I think.
Tor's function style is
{{{
return_type
function_name(args)
{
...
}}}
but in a few places, this patch puts the { on the same line as the args.
By convention, we should almost always have the name for a torrc entry be
the same as the name for its field in or_options_t: it cuts down on
confusion. Also, we keep
_option_vars in alphabetical order for some reason.
Re-parsing all the transport lines for each bridge seems off. Can we just
parse all the transport lines first, then parse the bridge lines?
Spelling in connection_or_finished_connecting: "pluggable", not
"pluggalbe".
This makes me worried:
{{{
transport = find_bridge_transport_by_addrport(&addr, port);
tor_assert(transport);
}}}
That can't be right, can it? Back in bridge_add_from_config, we didn't
give every bridge a transport.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2841#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs