Hello,

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.
I was interested in implementing this feature myself, and I wanted to
get some feedback on what I was considering.

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).

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.

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
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).

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.

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)
    5) Possibly a flag to wait for a response when sending a command.
This would be used for post-processing, as mentioned above.

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). 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]". I'm sure there are other
possibilities beyond these.

Please let me know if I've overlooked something or if you have any suggestions.


_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to