On 31 Oct 2017, at 06:57, David Goulet dgoulet@ev0ke.net wrote:
- I believe now that we should seriously discuss the relevance of channels.
Originally, the idea was good that is providing an abstraction layer for the relay to relay handshake and send/process cells related to the protocol. But, as of now, they are half doing it.
There is an important cost in code and maintanance of something that is not properly implemented/finished (channel abstraction) and also something that is unused. An abstraction implemented only for one thing is not really useful except maybe to offer an example for others? But we aren't providing a good example right now imo...
That being said, we can spend time fixing the channel subsystem, trying to turn it in a nicer interface, fixing all the issues I've described above (and I suspect there might be more) so the cell scheduler can play nicely with channels. Or, we could rip them off eliminating lots of code and reducing our technical debt. I would like us to think about what we want seriously because that channel subsystem is _complicated_ and very few of us fully understands it afaict.
It depends what the goal of the channel layer is.
Do we seriously think we will use another protocol in place of TLS?
Even if we are serious about non-TLS connections, do we want to rip out this code now, and write something better when we know what we actually need?
Is the channel layer the right place to hide the differences between TLS-over-IPv4 and TLS-over-IPv6? (I don't think it is, but it's worth thinking about how much work it was to add IPv6 support, and using that as a guide for how much work it would be to add address/port/keys/etc. for another protocol.)
T