It feels like English is ill-equipped for naming components of a bidirectional communication system.
Uncategorized
6
Posts
2
Posters
1
Views
-
It feels like English is ill-equipped for naming components of a bidirectional communication system. In QUIC they use `src_connection_id` and `dst_connection_id`, which is pretty confusing. And then there's tx and rx, which are also confusing. Maybe what you need is some canonical ordering, and to then name the two pipes based on that, rather than by their mode relative to the sender. e.g. if you make the channel Alpha be low connection-id to high connection-id. and channel Bravo, be high to low
-
It feels like English is ill-equipped for naming components of a bidirectional communication system. In QUIC they use `src_connection_id` and `dst_connection_id`, which is pretty confusing. And then there's tx and rx, which are also confusing. Maybe what you need is some canonical ordering, and to then name the two pipes based on that, rather than by their mode relative to the sender. e.g. if you make the channel Alpha be low connection-id to high connection-id. and channel Bravo, be high to low
Otoh basically everything in a networking system ends up having to deal with 'relativity', so perhaps it's a lost cause and you just need to embrace it.
-
It feels like English is ill-equipped for naming components of a bidirectional communication system. In QUIC they use `src_connection_id` and `dst_connection_id`, which is pretty confusing. And then there's tx and rx, which are also confusing. Maybe what you need is some canonical ordering, and to then name the two pipes based on that, rather than by their mode relative to the sender. e.g. if you make the channel Alpha be low connection-id to high connection-id. and channel Bravo, be high to low
@dotstdy As long as you are referring to the same stream from opposite ends, I think tx/rx is fine and not confusing. E.g. if you have a pipeline a => b => c it would be a_tx -> a_rx => b_tx -> b_rx => c_rx. Assuming this is referring to the actual sender/receiver handles.
-
@dotstdy As long as you are referring to the same stream from opposite ends, I think tx/rx is fine and not confusing. E.g. if you have a pipeline a => b => c it would be a_tx -> a_rx => b_tx -> b_rx => c_rx. Assuming this is referring to the actual sender/receiver handles.
@dotstdy While it's tolerable for the class names, I actually don't like sender/receiver as variable names since it conflates the handle/capability for sending/receiving with the identity of the sender and recipient. So I think that's a strong argument in favor of using something distinctive like tx/rx. Of course, tx can also mean transaction in some contexts, but it's usually not a problem.
-
@dotstdy While it's tolerable for the class names, I actually don't like sender/receiver as variable names since it conflates the handle/capability for sending/receiving with the identity of the sender and recipient. So I think that's a strong argument in favor of using something distinctive like tx/rx. Of course, tx can also mean transaction in some contexts, but it's usually not a problem.
@pervognsen Yeah, the thing which precipitated this thought was the connection id in quic which is endpoint specific, not directional per-se. And you have to send your connection id as part of the handshake. Which is a bit weird imo. But there's also symmetric keys which are attached to the direction, but used asymmetrically. I do agree about tx / rx though, that's the most reasonable thing I could come up with as well.
-
undefined oblomov@sociale.network shared this topic
-
@pervognsen Yeah, the thing which precipitated this thought was the connection id in quic which is endpoint specific, not directional per-se. And you have to send your connection id as part of the handshake. Which is a bit weird imo. But there's also symmetric keys which are attached to the direction, but used asymmetrically. I do agree about tx / rx though, that's the most reasonable thing I could come up with as well.
@dotstdy Are you still rolling your own? :)
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@samvarma correct. Also for anyone wondering, see picture alt texts for more context.
-
stop the count!
-
EU Sets Its Sights on VPNs as Age Checks Expand
They're starting to tighten and restrict our freedoms. It's time to stop them.
https://reclaimthenet.org/eu-targets-vpns-as-age-checks-expand
-
@evan The venn intersection of Alice and Bob's followers.
-
Nuovo episodio di @123podcast
S01E20: Le botte di Torino, gli antagonisti, la psicopolizia, il decreto sicurezza e il racconto di Roberto.
https://castopod.cgubi.synology.me/@123podcast/episodes/torino
-
@evan xitter not working that way was also the source of some easy social faux pas if you so much as forgot that one of the people in a thread had their account locked while you were looking at an individual post (in which case in practice you should stay out of it)
-
@inherentlee @mayintoronto @evan Yes, I mainly only use “followers only so it can’t be boosted”.
It never occurred to me to think of boost control as a potentially separate thing. That would be a good feature even in public posts.
-
@evan I chose Alice's followers on the understanding that "should" means "what I would expect to happen as a user and how I would want to strive to make it work as an implementor, even though I think that's not now it works now"
This is on the basis that I believe the replies to a standalone post belong "in the space" of that user's posts, and so they should "live" on their instance, and they should have ability to moderate within that space.
