On Mon, Oct 01, 2018 at 07:24:58PM +0200, Kristian Larsson wrote: > On 2018-10-01 10:02, Oswald Buddenhagen wrote: > > no, because these are clean interfaces, even if the data path is > > somewhat convoluted. > > Are they meant to be used that way or are they simply hacky ways of > using side effects of the current behaviour of the program? Do you > commit to supporting those cases and not changing as to cause backwards > incompatibility? > it's not clear what approach(es) in particular you're referring to (and even i don't remember everything i ever discussed), so i can't really answer that. ;) the file watcher approach is based on inherent mbsync/maildir properties, so there is just no way how i could break it. the notifier/callback approach (whichever one exactly makes it in the end) isn't going to go away in the forseeable future once in place.
> Nevertheless, I think it's way too convoluted for something that really > shouldn't be that hard... > well, i like generic solutions, and these have a tendency to be more complex than somebody who has a single use case in mind would have ever thought. ;) > nmap has -oG for greppable output. Can we have something similar? If we > clean up a patch that just writes the final state in a machine parseable > format? Could be key=value style or something else. > that's actually fairly compatible with the notifier approach - whether one dumps the "event log" to stdout, a file/fifo, or a popen()'d pipe doesn't make a whole lot of a difference, so all of these could be implemented with minimal overhead once the logging itself is there. speaking of "logging", i once started on making the debug and error logging more structured, but this turned out to be serious work and i lost interest - see wip/better-stderr branch. this work would be very much pertinent if one wanted to make a really generic event reporting mechanism, as that would obviously also need to include errors, not only statistics. > > i'll think some more about yuri's approach. i still don't like it, > > but it isn't worse than the lumped exit code that is already in > > place. > > That would work for me too. I wonder though, and I think it was you > who wrote this in a thread, I would like to differentiate between > whether the master or slave was updated and only trigger other > programs based on one. Do you see that going into the exit status? Or > do we loose some granularity? > i can't answer that without actually doing the work, which isn't really a priority for me currently. but i'm vaguely worried that we might run out of bits quickly. _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
