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: >> > 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.
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. >> 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. Thanks. >> > 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. Maybe on subsequent fetches, on the first fetch the priority is to get a working sync'ed folder. > 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. Sure, in subsequent fetches if I have a MaxMessages of 10, and I have 15 unseen messages, it makes sense to fetch them all. However, if I have MaxMessages 1000, and I have 1500 unseen messages, it really doesn't make sense to fetch 1500. It might make sense to fetch 1000 messages, and in further sync's prioritize the remaining 500. Unfortunately I think that might be very tricky to implement, and there's really not much return of investment for such a feature. Also, I doubt anybody would do MaxMessages 10. 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". >> > 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. 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? >> > 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. That's right. I would assume it's much easier to implement than MaxMessages with a sliding window that removes old ones. >> >> 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. If you mean MaxFetch, then yeah, the huge sync problem is gone. > 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. -- 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
