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: > > there are three levels of "noticing" messages: [...] > > [...] I don't think the Gmail web interface has any notion of that concept. > it's possible that the mailbox still has it in the background. i'll check that.
> > 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. > In fact, I would prefer it to be the maximum age, like in offlineimap, > so I can say: sync only the last month. > that sounds entirely doable. i'll put it on the todo. > > the assumption is that you wouldn't want to miss lots of messages just > > because you haven't been reading mail for a while. > > I have a folder with 120,000 unread messages, if I try to first fetch > with MaxMessages 100, I would get 120,000 messages. That's quite a > delta from what I requested. > indeed. > 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. this would be entirely reasonable if all the mail in the archive was actually already read. this is obviously not the case for you. > > it would be conceivable to add modes with lower levels of safety, which > > could be useful for "optional" mailboxes. option UnseenMessages: > > - Fetch: the current behavior. makes sure you miss no message. > > - Keep: keep already downloaded recent messages, but don't always fetch > > old unread ones. that means that the initial fetch will be (mostly *) > > hard-limited, but the box will grow if you regularly sync but don't > > even look at your mail. if you don't sync for longer than it takes to > > fill the window, there will be a "hole". > > Longer than it takes to fill the window? Which window? > 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. > > i don't understand the point of that. it seems arbitrary to limit the > > initial fetch to a smaller number of messages than you want to keep > > in the long run. > > Say I want to reply to a mail I got yesterday, I may do MaxMessages > 100 just to get it, and later on I want to download more, maybe 1,000. > Then 2,000, eventually I may get them all, but the important thing is > that it doesn't happen in one go and I can reply to the mail from > yesterday, today. > 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. > >> Currently: > >> 1) First fetch MaxMessages=1000, I get the last 1000 messages > >> 2) Subsequent fetches get the new messages after that, say over one > >> month 1000 new messages more > >> > >> I have 1000 messages locally. > >> > > yes. what's wrong with that? > > That I may want to search for older messages. Why delete them if I > already downloaded them? Storage is cheap. > the problem here is something that others have reported: keeping the huge archive in sync (even if nothing actually changes) costs a lot of bandwidth as well. to the point that google may throttle you. 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). now, bringing in the actual age of the messages opens a new possibility: that one *is* immediately obvious (provided the user keeps in mind the limit he set), so it would be a feasible cut-off. ------------------------------------------------------------------------------ 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
