← Back to team overview

syncany-team team mailing list archive

Syncany Daemon Concept - brainstorming


Hello again,

as promised, here's my mail about the daemon concept. I urge you to comment
and/or *voice your opinion about this* -- the daemon concept is not set in
stone, yet. Vincent has implemented a daemon that works quite well for the
GUI interaction (https://github.com/vwiencek/syncany/tree/gui), but not for
all of the use cases we need it for. So I think it's good to brainstorm
about this.

There are a couple of *reasons to implement a daemon* (= background
1. User interfaces (web, desktop/gui, file manager) should be able to get
folder/file status information and be notified about the events. This is a
major, major reason!
2. Plugins might need background processes running; e.g. the BT plugin
needs a seeder thread
3. The 'sy watch' command currently only runs in the foreground. If it is
sent to the background (on Linux with &), it must be stopped by killing it

The architecture of the daemon should allow the following things (
a. Export an interface for communication from GUIs, clients, etc. (via web
sockets + JSON; authentication interface required)
b. Allow plugins to run their own background thread; maybe control the
thread (start/stop/"pause")?
c. Host more or less generic threads: WatchOperation threads and plugin
threads (watch operation thread must be able to start plugin threads
d. Implement a "generic" message format that can be passed to the
responsible thread (e.g. "stop watch" needs to stop the correct
e. Anything else?

The CLI should be able to communicate with the daemon, but it should also
be able to communicate directly with the storage (as it is doing right now).

i. @Vincent: Do you think it's possible to separate the daemon branch from
the GUI branch, so we can work on the daemon separately for now? If so, can
you do that? If not, just let me know and I'll do it as soon as I find the
ii. It might be necessary to compare service wrappers. There are a few out
there. Any experiences? Anybody? Apache Commons Daemon [1], Launch4J [2] or
yajsw [3]?

Vincent's* current daemon implementation: *

---> I added a quick sketch of what I had in mind. Obviously we need to
talk more about communication and formats, but a diagram always helps :-)


[1] http://commons.apache.org/proper/commons-daemon/
[2] http://launch4j.sourceforge.net/
[3] http://yajsw.sourceforge.net/

Attachment: Syncany daemon brainstorming.jpg
Description: JPEG image