On Tue, Nov 5, 2013 at 5:43 AM, Oswald Buddenhagen <[email protected]> wrote: > On Tue, Nov 05, 2013 at 03:52:35AM -0600, Felipe Contreras wrote: >> On Tue, Nov 5, 2013 at 3:13 AM, Oswald Buddenhagen <[email protected]> wrote: >> > On Mon, Nov 04, 2013 at 10:37:43PM -0600, Felipe Contreras wrote: >> >> On Mon, Nov 4, 2013 at 6:00 PM, Oswald Buddenhagen <[email protected]> wrote: >> >> > it would be conceivable to add a mode where the local recency status is >> >> > ignored, so messages cannot be expired just because you opened the >> >> > mailbox. >> >> >> >> I don't know what expiring means. >> >> >> > being disposed of based on being not the newest, not important >> > (flagged/unseen), and in excess of the limit. >> >> Ah, you mean on subsequent fetches? If so then yes that's what I want, >> but you seem to imply the messages can still be disposed for some >> other reason. >> > no. "prune" is probably a better word than "expire". > i just meant optionally loosening the definition of important: > AlwaysFetch: Recent (provided it's possible after all), Unread, None.
I see, I would use the word "exclude", because they are being excluded from the sync. >> >> Why can't MaxMessages mean the maximum amount of messages, period? >> >> >> > because the assumption is that seeing the messages is more important >> > than limiting the fetch size. >> >> Maybe on subsequent fetches, on the first fetch the priority is to get >> a working sync'ed folder. >> > i must say, it never occurred to me to view the first fetch as anything > special. it's just something that happens in the background. > > if i really am in a hurry, i'd actually use on online-/web-client. That's what I've been doing for the most part, because I can't use anything else for most of my folders. > if you really want to use an offline-client in that case, you could > script MaxMessages being increased over time. though mbsync probably > won't work particularly efficiently in this case, if at all. I don't need that much flexibility. I would probably start with the messages of last week, so I can get started, then last month, maybe last year if I see the need. >> > this would be entirely reasonable if all the mail in the archive was >> > actually already read. this is obviously not the case for you. >> >> Yes, but I honestly don't see why you are assuming that. >> > that's how i work. "unread" means to me "must still read". if i find a > thread uninteresting, i just mark it as read. therefore, my archive > would never contain noteworthy amounts of unread mail, and i would want > to know if it did. And you assume everybody has the same habits as you? If not then you cannot assume that most of the mail is read. >> A simpler and saner approach to deal with the problem is to simply >> throw a warning: "There are still %i unsynchronized messages but we >> reached the maximum limit". >> > that doesn't help with selectively picking the unread mails. Sure it does. The user can increase the limit to get those, if that's what he wants. Or use a more appropriate option (AlwaysFetch: Recent). If that matters for him. >> > ok, that's an interesting perspective. you actually want MaxFetch (aka >> > MaxMessagesPerRun). >> > not sure how much i'd need to change to make this feasible. it puts >> > quite some assumptions upside down. >> >> That's right. I would assume it's much easier to implement than >> MaxMessages with a sliding window that removes old ones. >> > well, mbsync assumes that subsequent fetches get higher and higher uids. > incrementally extending the lower bound poses an interesting challenge. But that's true for both MaxMessages and MaxAge, no? >> > the idea i brought up before would be simply not syncing messages beyond >> > a certain count. >> > the problem with that is that this count is entirely >> > non-obvious when viewing the mailbox, so the results may be confusing >> > (suppose you flag a semi-old message, and then wonder why it wasn't >> > synced). >> >> Yeah, that is true. Another possibility would be to move these old >> messages to an archive, so they are not gone locally, the user can >> still find them, but it's clear that if they are in the archive they >> are not synced any more. >> > hmm, yeah, that may make sense. > > so there could be an option ExcessMessageMode: Prune (current), Keep > (just don't sync) and Archive (move to separate folder - ArchiveSuffix, > default .archive). Right, that sounds great. > so what are your priorities, given the effort (and consequently timing) > estimates? > - AlwaysFetch (easy) This is by far the most important I think. As it has been said before lots of people _need_ MaxMessages for mbsync to be useful, and if they have lots of unread messages they also need this option or MaxMessages is not that useful. > - MaxAge (medium) Probably this one as #2, as I think most people would prefer MaxAge to MaxMessages. > - ExcessMessageMode (medium) Personally I would love this one, but I don't think it's really _needed_ for most people. So #3. > - MaxFetch (unknown) I think there was a confusion here. I thought by MaxFetch you meant that the local messages were not removed (ExcessMessageMode: Keep). I don't think anybody needs a limit per run, I certainly don't. If we get MaxMessages+AlwaysFetch (None), I could finally start using mbsync fully :) Cheers. -- Felipe Contreras ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
