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
-- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
