<div dir="ltr"><div>Hi I looked into the storage problem some time ago, and I think Klass could solve it with some evolution of the current client (and its local usage of SQLite), but to justify my thinking a little bit of background analysis is required:</div>
<div><br></div><div>File usage has some pretty consistent characteristics amongst my near peers:</div><div><br></div><div>There is a high frequency usage of small files and low frequency usage of large files i.e. powerlaw relationship:</div>
<div>1. At the one end of the spectrum I want files that I use frequently on my local device(s), so I do not have to wait for download.</div><div>2. At the other end of the spectrum I have files that I rarely use, but want access to at some unpredictable point in time within the next two decades.</div>
<div>3. Files I use often are relatively small, and in contrast, the files I rarely use are rather large. </div><div>4. There are lots of small files and less larger ones.</div><div><br></div><div>Behaviour:</div><div>5. Users want access to their files from multiple devices of different specification; a personal example is:</div>
<div><span class="" style="white-space:pre">    5</span>.1 I have* 2Gb for files on my mobile</div><div><span class="" style="white-space:pre">     5</span>.2 I have* 70Gb for files of 128 Gb SSD on my laptop</div><div><span class="" style="white-space:pre">      5</span>.3 I have* 90Gb for files of 160Gb desktop.</div>
<div><span class="" style="white-space:pre">    5</span>.4 I have* 3 Tb for files on my OwnCloud server (always online, with fixed tcp/ip) - this could very well be other scale out services as well.</div><div><span class="" style="white-space:pre">    5</span>.5 Each device will be online at random times, and they can connect securely together:</div>
<div><br></div><div>The trick that makes it <u>irrelevant</u> how much local disk space I have, is that I permit LOCAL OVERWRITE IFF there is GLOBAL REDUNDANCY (via OwnCloud). </div><div><br></div><div>If a file is updated on the one device I want it up-to-date on the other devices as soon as possible (via web), but only IF it is used MORE THAN ONCE on the other devices. This means all files are listed (A lot of JSON-type symbolic file-links that take up 1-2kb max), but all files are as JSON-links until used the first time (just like as with google drive installed on windows).</div>
<div><br></div><div>This requires that the OwnCloud client monitors the file system (iNotify or similar), and uses statistics of file-usage PER DEVICE PER USER to stay up-to-date. </div><div>First it must assure that 1 copy of local files are up-to-date on the OwnCloud Server whilst the OwnCloud must have sufficient capacity to "back the local file up".</div>
<div>Second it must prioritize synchronization as a schedule, and not simply perform a braindead mirror of N nodes (as it does currently).</div><div><br></div><div>For practical purpose of such prioritization a vector that contains exponential function of "time since last usage" x "frequency of usage" would suffice.</div>
<div><br></div><div>The point here that the user NEVER runs out of space on a single device, because the files which are not used after a certain amount of time are release for overwrite the moment the space is needed for other -  arguably more relevant files - or they are simply not downloaded to the local device (because they exist locally as pointer with JSON link).</div>
<div><br></div><div>Please notice that overwritten in this context means that the "111010101"-blob on your LOCAL device is substituted with a JSON link to the copy on OwnCloud (if this is more feasible utilisation of the limited space on the client). </div>
<div>The local pointer to the file X is only change from the pointer named X that refers to iNode so-and-so-much to a pointer named X that refers to JSON that points to OwnCloud. </div><div>Hereby the local file X is released to be deleted/overwritten (depending on the HW-driver setting) whilst UI the content underneath the UI simply changes to point at the OwnCloud. Obviously this overwrite is only permitted IFF the file exists on the OwnCloud (i.e. has been uploaded).</div>
<div><br></div><div>So the trick in summary: Files which occupy a higher frequency of usage or generally just are new on the LOCAL devices, everything that does not fit in the space available locally exists on the OwnCloud, but is visible on the local device as a JSON-link that from the UI is visually identical the real file.</div>
<div><br></div><div style>For Klaas it means that iNode will change a lot (sorry) and that sha-256 should be packed into the JSON link or the sqlite db. I know Klass is working on that already.</div><div style>Also the client could read the sqlite database for updates instead of visiting the filesystem. To check if two databases are up-to-date a sha-256 of the database itself may be exchanged which drops the required communication (client-server) significantly at the first connection. The knowledge alone can permit a less power-consuming startup of connectivity in stead of the current where bandwidth is consumed naively. However these details are just the top of the iceberg. But I think OwnCloud client is the best match "out-there" for taking a step in that direction.</div>
<div><br></div><div>A wider intellectual challenge is to predict behaviour across devices which are idle are predict which files are to be used so that local devices are up-to-date using low-power connection BEFORE you pick them up and use them but I'm still working on that :-)</div>
<div><br></div><div style>Kind regards,</div><div style>Bjorn</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 May 2013 07:52, Jan-Christoph Borchardt <span dir="ltr"><<a href="mailto:hey@jancborchardt.net" target="_blank">hey@jancborchardt.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As a Chromebook owner who put Ubuntu on it: The main concern or solution here seems to be to make ownCloud cope better with being offline. Use more client (JS) and less server (PHP) logic, use local browser databases for data caching (localStorage, indexedDB) and cache the apps themselves (AppCache).<br>

<br>
That way there's also less dependence on the server and better performance because not everything has to be loaded again so often.<br>
<br>
Of course this involves major code forward, but the Appframework and newer apps already are on the path to this. Also solves one of my pet peeves: the files app reloads every time you click a folder …<br>
<br>
This would also make ownCloud better compatible with Firefox OS. Would be quite strange to make "thin client apps" for the "fat web frontend" instead of just improving it for everyone.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Owncloud mailing list<br>
<a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Bjorn Madsen</div><div><i>Researcher Complex Systems Research</i></div><div>Ph.: (+44) 0 7792 030 720 </div><div><a href="mailto:bjorn.madsen@operationsresearchgroup.com" target="_blank">bjorn.madsen@operationsresearchgroup.com</a></div>
<div><br></div>
</div>