[Owncloud] ownCloud Client 1.0.4 Release

[Emre Erenoglu]

On Sun, Aug 12, 2012 at 3:09 PM, Jono <jono at foodnotblogs.com> wrote:

> On Sat, Aug 11, 2012 at 2:20 PM, Steve Riley <steve at rileyz.net> wrote:
> > On 2012-08-11 06:59:43 Jono <jono at foodnotblogs.com> wrote:
> >>
> >> Yes, the client periodically polls the server to look for updates. A
> >> way around this is to have something push from the server to connected
> >> clients. Like a process that manages client connections. I am not sure
> >> how "Unison and inotify" would solve this problem though.
> >
> > I've seen a few posts around the web describing how to build
> Dropbox-like two-
> > way sync with Unison and inotify. I was simply curious whether OwnCloud
> might
> > be able to adopt a similar approach. inotify is neat because it responds
> to
> > kernel notification about file changes, avoiding the need to continually
> poll
> > for those.
>
> The owncloud client is using inotify to listen for local file changes.
> It can not be used to listen for remote file changes. And it uses the
> csync library which performs two way file sync just like unison.
>

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:
Looking for changes  (for local files)
  Waiting for changes from server (for remote files)

So yes, owncloud already behaves as these solutions you have read
> about. The only problem is how does the client determine when a file
> changes on the server. That is where polling occurs. "Unison and
> inotify" does not address this problem because these are things
> initiated from the client to the server. You would need an additional
> technology to initiate commands from the server to the client, if you
> want to remove polling altogether.
>

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.

I tried to discuss this in a thread called "server participation" some time
ago in the list.
-- 
Emre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20120812/1cb26161/attachment.html>