Re: [commit] master: deprecate master/slave terminology

2020-08-30 Thread Yuri D'Elia
On Sun, Aug 30 2020, Oswald Buddenhagen wrote:
> On Sun, Aug 30, 2020 at 01:06:57AM +0200, Yuri D'Elia wrote:
>> Can we have a reciprocal of MaxMessages that applies to the "far" side
>> instead? That is, I want my "near" side to be the complete reference,
>> and far only being a partial copy.
>> 
> i never understood your motivation for that. care to elaborate?

If you consider MaxMessages, isync assumes the mail mailbox that
receives new mail is remote and/or that the remote side has all the
mail, while you might wish to keep a partial copy of the most recent
messages locally.

In my case it's exactly the opposite. I fetch mail and deliver most of
my mail locally from various sources. I keep a slice synced remotely, so
I can have some archive just in case I view it through webmail for a day
or two, essentially as a backup.

In this scenario Master/Slave worked just fine, although push/pull was
flipped. Now the entire logic is flipped. I guess it's more
consistent =)



___
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel


Re: [commit] master: deprecate master/slave terminology

2020-08-30 Thread Oswald Buddenhagen
On Sun, Aug 30, 2020 at 01:06:57AM +0200, Yuri D'Elia wrote:
> Can we have a reciprocal of MaxMessages that applies to the "far" side
> instead? That is, I want my "near" side to be the complete reference,
> and far only being a partial copy.
> 
i never understood your motivation for that. care to elaborate?

> I wonder if other flags apply in a similar way.
> 
without checking, i can think of only SyncState *, where the box being
"near" is actually a precondition (i.e., it must be maildir).


___
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel


Re: [commit] master: deprecate master/slave terminology

2020-08-29 Thread Yuri D'Elia
On Sat, Aug 29 2020, Oswald Buddenhagen wrote:
> i'm still waiting for the brilliant alternative to the push-pull mental 
> model. ;)

Maybe I'm looking at this wrong. If Near/Far had no distinction, I
couldn't care less.

Can we have a reciprocal of MaxMessages that applies to the "far" side
instead? That is, I want my "near" side to be the complete reference,
and far only being a partial copy.

I wonder if other flags apply in a similar way.



___
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel


Re: [commit] master: deprecate master/slave terminology

2020-08-29 Thread Oswald Buddenhagen
On Sat, Aug 29, 2020 at 08:29:44PM +0200, Yuri D'Elia wrote:
> On Tue, Aug 04 2020, Oswald Buddenhagen via isync-devel wrote:
> > the far/near terminology has been chosen as the replacement, as it is a
> > natural fit for the push/pull terminology. on the downside, due to these
> 
> I would have preferred something that doesn't imply a location. Now that
> I'm adjusting my config, it's really not natural for the case where
> "Far" is actually local. Doesn't make any sense really.
> 
> Thinking again, I would have gone for Master/Copy.
>
i'm still waiting for the brilliant alternative to the push-pull mental model. 
;)

> But I guess it's too late :(
> 
it would have to be truly brilliant to do another 2000+ line patch (or
force push the whole thing again ...).


___
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel


Re: [commit] master: deprecate master/slave terminology

2020-08-29 Thread Yuri D'Elia
On Tue, Aug 04 2020, Oswald Buddenhagen via isync-devel wrote:
> the far/near terminology has been chosen as the replacement, as it is a
> natural fit for the push/pull terminology. on the downside, due to these

I would have preferred something that doesn't imply a location. Now that
I'm adjusting my config, it's really not natural for the case where
"Far" is actually local. Doesn't make any sense really.

Thinking again, I would have gone for Master/Copy.
But I guess it's too late :(



___
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel


[commit] master: deprecate master/slave terminology

2020-08-04 Thread Oswald Buddenhagen via isync-devel
commit c8f402e43f9c6a3c685fe0f716ffda741beeac13
Author: Oswald Buddenhagen 
Date:   Wed Jul 22 19:44:26 2020 +0200

deprecate master/slave terminology

the underlying metaphor refers to an inhumane practice, so using it
casually is rightfully offensive to many people. it isn't even a
particularly apt metaphor, as it suggests a strict hierarchy that is
counter to mbsync's highly symmetrical mode of operation.

the far/near terminology has been chosen as the replacement, as it is a
natural fit for the push/pull terminology. on the downside, due to these
not being nouns, a few uses are a bit awkward, and several others had to
be amended to include 'side'. also, it's conceptually quite close to
remote/local, which matches the typical use case, but is maybe a bit too
suggestive of actually non-existing limitations.

the new f/n suffixes of the -C/-R/-X options clash with pre-existing
options, so direct concatenation of short options is even less practical
than before (some suffixes of -D already clashed), but doing that leads
to unreadable command lines anyway.

as with previous deprecations, all pre-existing command line and config
options keep working, but yield a warning. the state files are silently
upgraded.

 NEWS|   2 +
 TODO|   8 +-
 src/config.c|  95 +-
 src/config.h|   1 +
 src/main.c  | 160 +
 src/mbsync.1|  54 +++---
 src/mbsyncrc.sample |  26 +--
 src/run-tests.pl| 104 +--
 src/sync.c  | 410 ++--
 src/sync.h  |  10 +-
 10 files changed, 450 insertions(+), 420 deletions(-)

diff --git a/NEWS b/NEWS
index 4133a50..8b6aae1 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,8 @@ The IMAP user query can be scripted now.
 
 Added built-in support for macOS Keychain.
 
+The use of Master/Slave terminology has been deprecated.
+
 [1.3.0]
 
 Network timeout handling has been added.
diff --git a/TODO b/TODO
index 66c9489..7a6c98d 100644
--- a/TODO
+++ b/TODO
@@ -15,7 +15,7 @@ should complain when multiple Channels match the same folders.
 propagate folder deletions even when the folders are non-empty.
 - verify that "most" of the folders in the Channel are still there.
 - refuse to delete unpropagated messages when trashing on the remote side.
-- refuse to delete master if it has unpropagated messages. symmetry?
+- refuse to delete far side if it has unpropagated messages. symmetry?
 
 add message expiration based on arrival date (message date would be too
 unreliable). MaxAge; probably mutually exclusive to MaxMessages.
@@ -28,9 +28,9 @@ add support for event notification callbacks.
 it would be also possible to report more differentiated exit codes, but
 that seems too limiting in the general case.
 
-make it possible to have different mailbox names for Master and Slave in
+make it possible to have different mailbox names for far and near side in
 Patterns.
-- use master:slave for the pattern
+- use far:near for the pattern
   - for quoting, use more colons: the longest sequence of colons is the
 separator
 - this makes Groups mostly useless, as they are mostly a workaround for this
@@ -63,7 +63,7 @@ use MULTIAPPEND and FETCH with multiple messages.
 
 create dummies describing MIME structure of messages bigger than MaxSize.
 flagging the dummy would fetch the real message. possibly remove --renew.
-note that all interaction needs to happen on the slave side probably.
+note that all interaction needs to happen on the near side probably.
 
 don't SELECT boxes unless really needed; in particular not for appending,
 and in write-only mode not before changes are made.
diff --git a/src/config.c b/src/config.c
index 5ba3724..e6d0ff4 100644
--- a/src/config.c
+++ b/src/config.c
@@ -174,21 +174,21 @@ getopt_helper( conffile_t *cfile, int *cops, 
channel_conf_t *conf )
else if (!strcasecmp( "Flags", arg ))
*cops |= OP_FLAGS;
else if (!strcasecmp( "PullReNew", arg ))
-   conf->ops[S] |= OP_RENEW;
+   conf->ops[N] |= OP_RENEW;
else if (!strcasecmp( "PullNew", arg ))
-   conf->ops[S] |= OP_NEW;
+   conf->ops[N] |= OP_NEW;
else if (!strcasecmp( "PullDelete", arg ))
-   conf->ops[S] |= OP_DELETE;
+   conf->ops[N] |= OP_DELETE;
else if (!strcasecmp( "PullFlags", arg ))
-   conf->ops[S] |= OP_FLAGS;
+   conf->ops[N] |= OP_FLAGS;
else if (!strcasecmp( "PushReNew", arg ))
-   conf->ops[M] |= OP_RENEW;
+   conf->ops[F] |= OP_RENEW;