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.
> >> 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. 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. > > 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. > 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. > > the sliding window of synced messages. if you sync 1000 messages, and > > then again after 500 more messages were delivered, without opening the > > mailbox in between, you'll now have 1500 consecutive messages. but if > > you wait until 1500 more messages were delivered before the second > > fetch, you'll have 2000 messages: the 1000 most recent at the time of > > each fetch, and 500 "in the middle" missing. > > Yeah, I think that's reasonable to expect. However, if the user > notices this hole, he might temporarily do MaxMessages 2000 (or even > 3000 just to be sure), and the hole would be gone, right? > in principle, yes. though the remaining unread mails would trickle in anyway after the other mails were read (and subsequently pruned). > > 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. > > 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). so what are your priorities, given the effort (and consequently timing) estimates? - AlwaysFetch (easy) - MaxAge (medium) - ExcessMessageMode (medium) - MaxFetch (unknown) ------------------------------------------------------------------------------ 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
