syncany-team team mailing list archive

[Philipp Heckel <philipp.heckel@xxxxxxxxx>]

Hello everyone,

I just got home so this is going to be short:

*Roadmap:*
The roadmap Fabrice pointed out was basically what I had in mind all along
-- except that I think the database stuff is essential for a
cleanup-operation. When 'cleanup' is implemented, Syncany can be considered
"feature-complete" for the first iteration. Without 'cleanup' and an
SQL-based local database, it's not able to run very long without creating a
memory issue (every file/chunk/multichunk in all versions is kept in
memory!)

*Wiki vs. Google Drive:*
Github has a Wiki, let's use it :-) I'll have time tomorrow (Tuesday)
night. If you want, you can start drafting before that.

*Gradle:*
I like it very much and I think it's the way to go. I have a few more
tiny(!) problems:

1. Running "sudo ./gradlew fakeinstall" creates some files in
.gradle/../../emptySomething.txt that are created by root, and are hence
undeletable if "./gradlew clean" is run be the normal user. Fakeinstall
should probably run a chown on .gradle somehow...

2. I still don't like that the wrapper jar is in the repo. Is this the only
way to do it? It's like putting an exe-file in there -- some people might
not trust what it's doing. Is it possible to download it when it's first
run?!

3. We should not base the gradle stuff on a new repo (like in
"syncany-gradle"). Instead, once we're sure that syncany-gradle is good and
ready, we should use the normal "syncany" repo so we keep the history. We
should also make sure all the branches immediately follow this change,
because otherwise this is going to be a mess.

*REST in for daemon/GUI communication:*
I like the REST construct in the daemon, because it's easy to implement for
all kinds of clients (mobile, web, desktop). However, I am very unclear how
to implement push notifications for these clients. Vincent proposed a REST
server in the GUI -- I find this a bit odd to be honest. I'd much rather
see some actual messaging. There are a few options: JMS, WebSockets,
REST-based long-polling, pub/sub a la fanout, etc. -- any ideas?

Even though long-polling is not very chic, it has the advantage that the
daemon/service only has to implement *one* server, listening on *one* port.
And client's do not have to "speak" multiple protocols.

*Issues with 'real-time file watching'*:
Honestly, I don't see this as a big deal anymore. I used to, because I
wanted to perfectly follow all files and record/process these changes. This
"RecursiveWatcher" was a nightmare back in the old Syncany. I was doing too
much. The current implementation is much simpler: events are only
registered and trigger a 'sync' (after a settlement of 3 seconds). Look at
the WatchOperation for details. However, I agree that this might get very
complex and hard to test very quickly, so I agree with taking it slow here.

With regard to the unreliable/unpredictable storage: This should be assumed
anyway -- that's why I created the "UnreliableLocalPlugin". There are not
many tests yet, but it's really easy to simulate any storage failure with
this plugin.

Best
Philipp