<div class="gmail_quote">On Sun, Aug 12, 2012 at 3:09 PM, Jono <span dir="ltr"><<a href="mailto:jono@foodnotblogs.com" target="_blank">jono@foodnotblogs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Aug 11, 2012 at 2:20 PM, Steve Riley <<a href="mailto:steve@rileyz.net">steve@rileyz.net</a>> wrote:<br>
> On 2012-08-11 06:59:43 Jono <<a href="mailto:jono@foodnotblogs.com">jono@foodnotblogs.com</a>> wrote:<br>
>><br>
>> Yes, the client periodically polls the server to look for updates. A<br>
>> way around this is to have something push from the server to connected<br>
>> clients. Like a process that manages client connections. I am not sure<br>
>> how "Unison and inotify" would solve this problem though.<br>
><br>
> I've seen a few posts around the web describing how to build Dropbox-like two-<br>
> way sync with Unison and inotify. I was simply curious whether OwnCloud might<br>
> be able to adopt a similar approach. inotify is neat because it responds to<br>
> kernel notification about file changes, avoiding the need to continually poll<br>
> for those.<br>
<br>
</div>The owncloud client is using inotify to listen for local file changes.<br>
It can not be used to listen for remote file changes. And it uses the<br>
csync library which performs two way file sync just like unison.<br></blockquote><div><br></div><div>Not exactly like unison as the server side participates in the sync process for unison(ie checks and reports changes to remove, writes the delta-sync info it receives from remote to the local files), while csync performs everything on the local side. You can see this when you run unison, it states:</div>
<div><div>Looking for changes  (for local files)</div><div>  Waiting for changes from server (for remote files)</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So yes, owncloud already behaves as these solutions you have read<br>
about. The only problem is how does the client determine when a file<br>
changes on the server. That is where polling occurs. "Unison and<br>
inotify" does not address this problem because these are things<br>
initiated from the client to the server. You would need an additional<br>
technology to initiate commands from the server to the client, if you<br>
want to remove polling altogether.<br></blockquote><div><br></div><div>Well, the inotify effort for unison (repeat watch, still  buggy in my practice) works on both sides. So the unison running locally uses inotify for local files and propagates to remove if it detects a change, while the unison running on the server does the same with inotify, for remote files.</div>
<div><br></div><div>I tried to discuss this in a thread called "server participation" some time ago in the list.</div></div>-- <br>Emre<br>