On Tue, Jul 02, 2019 at 09:15:00PM -0500, Sam Lunt wrote: > Skimming through the archives, I've seen a few mentions of adding > support for a daemon mode but it doesn't look like it's happened yet. > correct. one of them contains a somewhat extensive action plan, which i have the impression you have seen.
> I was interested in implementing this feature myself, and I wanted to > get some feedback on what I was considering. > excellent. > 1. The main use case I have for this feature is password caching. I > currently use a systemd user timer to fetch mail in the background, > but since I encrypt my passwords with gpg, this leads to prompts from > the gpg-agent every so often. I'd plan to have the daemon cache > passwords and only re-run the PassCmd if the fetch command fails (this > is to handle the situation where the password has changed). > yeah, as the TODO says since before my time. :-) > 2. I'd plan to support both SysV and "New-style" daemon modes, as > outlined in daemon(7). I would use a UNIX socket for communication, > which would be provided by systemd in "new style" mode and created by > mbsync otherwise. > you can lift the code for that from https://github.com/KDE/kde-workspace/blob/KDE/4.11/kdm/backend/ctrl.c (server) and https://github.com/KDE/kde-workspace/blob/KDE/4.11/kdm/kfrontend/kdmctl.c (client) - it's fully owned by me, so no need to retain x11 copyright headers. adjustments to the surrounding infrastructure and coding style would be required, of course. > 3. I wouldn't add any support for a timer that would periodically run > a sync command. I have two reasons for this, but I'm open an argument > in favor of such a feature > > The first reason is that this use case seems to be easy enough to > implement using cron or a systemd timer, so delegating to those > utilities reduces the amount of complexity that must be added. > that's correct from a modularity perspective, but as an actual user who wants to get the job done it's rather annoying - more stuff to learn (or refresh) and more places to deal with config. modularity starts to pay off only once a certain system size is exceeded. > That would also increases the flexibility, since the cronjob/timer can > pass whatever options it likes (e.g. one group is synced every 15 > minutes while another is synced every hour). > per-group (or actually, per-channel) timing shouldn't be harder to implement than a single global timer, so that argument in particular is not very strong. > The second is that both of those utilities will better support the use > case of running mbsync and then running something like notmuch after > the sync is complete. If the timer lived inside the mbsync binary, > then there would need to be a way to configure a post-sync command (or > to notify some other utility). The one obstacle to this is that it > would require some way for the "mbsync client" to be notified when the > sync is complete. Normally it would be sufficient to send the message > to the socket and then exit, but that wouldn't be true if you wanted > to run a command once the sync is complete. > indeed, that has been discussed here to a somewhat significant extent, iirc in multiple threads. note that when the process is driven by mbsync itself (inotify, imap IDLE, etc., which are on the TODO), then some notification system is required anyway. that could of course be implemented via an "idle" command in the mbsync socket protocol, but then one would *have* to run mbsync in daemon mode, and the client code would be somewhat complex by scripting standards, too. so overall, your model works best if you assume a "dumb worker" role for mbsync, but that's not necessarily what you should aim for, again based on the fact that tight integration is more convenient for such small tools. rethink the overall system design before pursuing the approach. > 4. I'd like some input on what command-line options should be added. I > can see the need for either four or five new parameters: > 1) A flag to indicate that mbsync should start a SysV style daemon > 2) A flag to indicate that mbysnc should start a "New-style" daemon > 3) A flag to indicate that mbsync should send a command to a > running daemon process > 4) An option to pass the path of the socket. This could be used > when sending a message and when starting a SysV style daemon (it would > default to /tmp/mbsync-$(id -u) if not supplied) > that isn't a very good path. use the per-user systemd run path, and if that doesn't work, drop it into $HOME (~/.mbsyncctl or some such). > 5) Possibly a flag to wait for a response when sending a command. > This would be used for post-processing, as mentioned above. > the protocol would more or less inherently provide that. question is only whether you'd make it synchronous with optionally async commands which return success as soon as they are accepted, or fully async like imap (which is more work to deal with on both ends). > Some of these could be combined in different ways. One way to combine > 1) and 2) is "--daemon[=sysv|systemd]" (names subject to bike > shedding, of course). > parsing "assignment-style" options is not implemented (unless you take the equal signs literally, which would work for fixed options but not for paths). so dashed flags and separated arguments. we can bikeshed the details later. > Other option would be to have both option 1) and 3) take an optional > parameter indicating the path to the socket, e.g "--sysv[=path]" and > "--daemon-send[=path]". > the path is necessary in the client as well, so it is probably a better idea to have it in the config file only. note that someone recently posted a few patches which i have been shamefully neglecting. one of them adds systemd autoconf handling. _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
