Postoffice / postbox? It's about mails after all, isn't it? :-)
On Tue, Jul 14, 2020 at 07:13:50PM +0200, Oswald Buddenhagen wrote: > On Tue, Jul 14, 2020 at 09:29:39AM -0400, Andy W wrote: > > Maybe getting away from the fundamental idea of directionality isn't at > > all possible, > > > well, of course not. > > > or at least implicit directionality? > > > huh? > the idea is to avoid suggesting a _particular_ direction (too strongly). > > > So, with that in mind, how about: "head" and "heel" ? > > > that's like north and south, only doubly so. > > On Tue, Jul 14, 2020 at 01:52:33PM +0000, ARaspiK via isync-devel wrote: > > this/that? > > > no shit - i had that idea as well. then i laughed it off. :-D > > > here/there? > > > like local/remote, only more silly-sounding. but see below. > > On Tue, Jul 14, 2020 at 07:03:11AM -0600, t...@tkware.info wrote: > > How about left/right? > > > that may sound silly, but this fits the idea of equality *too* well. :-D > (there is slight asymmetry between the sides relating to MaxMessages and > SyncState, and *usually* most data flows in one direction, so i think it > makes sense if the names give a slight hint, like the parent/child > proposal.) > > but then, there is this entry in the TODO file: > > > - use master:slave for the pattern > i.e., the keywords themselves would disappear from the config file anyway. > however, references in various other contexts would remain, and left/right > would follow the syntax. but so would first/second. > > On Tue, Jul 14, 2020 at 09:48:41AM -0400, Stefan Monnier wrote: > > Aren't they individually and explicitly given a meaningful name already > > anyway? > > > > Endpoint :work-remote: > > Endpoint :work-local: > > > then declaration order would have to define the assignment of the side, as > the relative location is important (pull vs. push). and there would be also > the question how to refer to these in various messages and command line > arguments, as explicitly naming them is not always practical. so this is > actually quite similar to the previous paragraph. > > hmm, push/pull actually assume a near/far (new proposal!) mental model, > which is just mildly different from the local/remote one. without that, the > assignment is arbitrary (which it currently is; i remember how i struggled > to get it straight in my head). so, push/pull is up for debate as well, and > proposals which consistently integrate both location and direction are > preferred. > > On Tue, Jul 14, 2020 at 04:58:32PM +0300, Roman Bolshakov wrote: > > Another alternative for the replica is "peer". No hierarchy implied. > > > just "peer" doesn't work, because we need two of them. > > > Some of the changes look like virtue signalling to me because they have > > no impact on daily life of the oppressed group while being actively > > promoted as such. > > > you're misunderstanding the term. you're referring to *bad* virtue > signaling. see > https://freethoughtblogs.com/atrivialknot/2016/09/16/virtue-signalling-is-not-pretending/ > > > The renamings don't solve a problem and don't help black people to > > suddenly join the industry, rather they distract, divide and confuse the > > development community (including developers outside the US). > > > this isn't about fixing inequality, but about not standing in the way of > fixing inequality. when you insist on using a metaphor that refers to > something fundamentally inhumane, you show that you have no respect for the > people who are rightfully triggered by it, and that certainly doesn't help. > https://cdm.link/2020/06/lets-dump-master-slave-terms/ is the best article > on the matter i could quickly find. > > fwiw, my personal boundary are words which are objectively *not* related to > racism, etc., say blacklist/whitelist. however, even in such cases there are > often technical reasons of accuracy and translatability to prefer something > else over a metaphor. > > > _______________________________________________ > isync-devel mailing list > isync-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/isync-devel _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
