On Thu, Feb 23, 2017 at 07:09:51PM +0100, Yuri D'Elia wrote: > On Thu, Feb 23 2017, Oswald Buddenhagen wrote: > >> I see the use case when running as a daemon. > >> > >> You still need to specify the indexing status to the child process > >> though. Would the same scheme be fine? > >> > > i'm not sure i understand the question ... > > > > i'd spawn one notifier per successful run on a single box. > > I should have written/meant "sync status" or process status.
> I'd like to know if, for instance, there's a transient failure (such as > connection error that I should not worry about). > really? your scriptlet below doesn't indicate that you do. what would you use it for? anyway, this is not exclusive. the point was merely that notifications about individual mails would be batched if a callback was used. > It's actually quite simple and very powerful. I wouldn't be able to do > this in daemon mode, for example. > i see no inherent reason why that should be the case. > I actually have different groups that I sync at different frequency > intervals, or some groups that I only sync when I'm in certain > networks. > different triggers in daemon mode have been discussed on this list previously. > I guess this would come in handy if you wanted to process imap mail > locally. But seems overkill just for a general status change. > "processing" would specifically mean "show a desktop notification for selected folders". > > one thing to consider: you're really just interested in changes on the > > slave, so it probably makes sense to realize the whole thing > > asymmetrically. this is equally true for your approach. > > Yes, I thought about that, since the counters are already split. > But I can actually avoid running the re-index in the vast majority of > the cases that even by combining them that it didn't seem necessary. > huh? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
