<html><head></head><body>Nice Work! Is it implemented as an app? Then the admin can deactivate background jobs by disabling the app, anyway.<br>
<br>
With regard to AJAX: what is our approach to various apps all wanting to make calls in the background. Possibly freezing the browser ui when using up all available connection (2 I think). Do we have some kind of queue for ajax calls? Should app authors always use the background jobs?<br>
<br>
So long<br>
<br>
Jörn<br>
-- <br>
Jörn Friedrich Dreyer (jfd@owncloud.com)<br>
Software Developer<br>
ownCloud GmbH<br>
<br>
Your Data, Your Cloud, Your Way!<br>
<br>
ownCloud GmbH, GF: Markus Rex, Holger Dyroff<br>
Schloßäckerstrasse 26a, 90443 Nürnberg, HRB 28050 (AG Nürnberg)<br><br><div class="gmail_quote"><br>
<br>
Jakob Sack <mail@jakobsack.de> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">I removed the option from the UI. In the program code the option "none" <br />is still usable.<br /><br />Am 11.08.2012 23:08, schrieb Jan-Christoph Borchardt:<br />> Ah sorry, I phrased it wrong. I didn’t mean »just use AJAX all the<br />> time and remove the option for cron jobs«, I meant »AJAX is always<br />> available and has no negative effect, so let’s just not have an <br />> option<br />> to deactivate background jobs«.<br />> Of course if the server supports it, cron should be used.<br />><br />><br />> TL;DR: Nice, let’s remove the option to deactivate background jobs.<br />><br />><br />><br />> On Sat, Aug 11, 2012 at 2:03 PM, Jakob Sack <mail@jakobsack.de> <br />> wrote:<br />>> Hi Jan,<br />>><br />>> thank you for the praise.<br />>> as far as I know there is no reason for completely disabling <br
/>>> background<br />>> jobs.<br />>> I strongly disaggree with you regarding your second argument. Using <br />>> AJAX<br />>> always is a bad idea. Exactly spoken, there are at least two <br />>> problems with<br />>> the ajax solution: if you installed ownCloud on a shared web hosting <br />>> service<br />>> and use it alone or with your family chances are high that there are <br />>> periods<br />>> with no one being online. Then you could miss news that are meant to <br />>> be<br />>> fetched every now and then. In this case a webcron serice would be <br />>> perfect.<br />>> On the other hand a large setup with several hundred users - we both <br />>> know<br />>> that they exist - should not be bombed with another hundred requests <br />>> every<br />>> minute. In this case it's better to use the systems cron service <br />>> which does<br />>&gt
 ; not
have the limitations apaches processes might have.<br />>> regards,<br />>><br />>> Jakob<br />>><br />>> Am 11.08.2012 20:30, schrieb Jan-Christoph Borchardt:<br />>><br />>>> Awesoooome! Does that mean that step-by-step, all the »refresh« and<br />>>> »rescan« buttons can go away?<br />>>><br />>>> Just one thing: You say »there are four options: using the systems<br />>>> cron feature, using a webcron service, using AJAX or not using<br />>>> background jobs at all.«<br />>>> Why even have the possibility to deactivate it? It’s a great <br />>>> function<br />>>> which improves the experience silently, as with doing away with the<br />>>> need for refresh buttons. And since doing it via AJAX is a good<br />>>> default there’s no reason to not just do it like that always – or <br />>>> is<br />>>> there?<br
/>>>><br />>>><br />>>> On Sat, Aug 11, 2012 at 7:07 AM, Jakob Sack <mail@jakobsack.de> <br />>>> wrote:<br />>>>><br />>>>> Hi,<br />>>>><br />>>>> yesterday I pushed the new Background Jobs system to ownCloud <br />>>>> master. As<br />>>>> you<br />>>>> can guess from the name, this feature allows ownCloud to do <br />>>>> certain tasks<br />>>>> in<br />>>>> the background without blocking the UI. It also makes it possible <br />>>>> to<br />>>>> execute<br />>>>> some tasks without any need of user interaction, for example <br />>>>> fetching<br />>>>> news<br />>>>> while the user is on holidays.<br />>>>> From a users perspective there is not much to pay attention to,<br />>>>> background<br />>>>> jobs 
 tries
to get out of the way as much as possible. On the other <br />>>>> hand,<br />>>>> administrators can use the settings interface to set the way <br />>>>> background<br />>>>> jobs<br />>>>> are executed. There are four options: using the systems cron <br />>>>> feature,<br />>>>> using<br />>>>> a webcron service, using AJAX or not using background jobs at all. <br />>>>> Using<br />>>>> the<br />>>>> systems cron feature is the preferred way. It allows regular <br />>>>> executed<br />>>>> jobs<br />>>>> without the limitations the web server may have. The second <br />>>>> recommended<br />>>>> option is the webcron implementation. By registering your ownCloud<br />>>>> cron.php<br />>>>> address at a webcron service like [1] you ensure that background <br
/>>>>> jobs<br />>>>> will<br />>>>> be executed regularly. Using AJAX is the default option, although <br />>>>> the<br />>>>> least<br />>>>> reliable. Every time a  user visits the page a single background <br />>>>> job gets<br />>>>> executed. The disadvantage of this solution compared to the <br />>>>> webcron<br />>>>> service<br />>>>> is that it requires regular visits of the page. The reason for <br />>>>> making<br />>>>> this<br />>>>> option the default is that this solution simply does not require <br />>>>> access<br />>>>> to<br />>>>> the system or registration on some third party service.<br />>>>> When you are implementing background jobs in your app, please be <br />>>>> aware of<br />>>>> the difference between the
AJAX/Webcron and the cron <br />>>>> implementation! The<br />>>>> AJAX/Webcron implementation gets started by <br />>>>> your-favorite-web-server, so<br />>>>> you<br />>>>> might have some limitations on execution time or memory. These<br />>>>> limitations<br />>>>> do not affect the system cron implementation, which calls php from <br />>>>> the<br />>>>> command line. As a consequence, you should split large tasks when <br />>>>> not<br />>>>> using<br />>>>> system cron. You can check whether the app has been started by <br />>>>> systems<br />>>>> cron<br />>>>> by checking if OC::$CLI is set to true.<br />>>>> If you want to  use background jobs in your app, you have to <br />>>>> register<br />>>>> them<br />>>>> in appinfo/app.php by calling
OCP\BackgroundJobs::addRegularTask( <br />>>>> $class,<br />>>>> $method ).<br />>>>> The first app featuring a background job is the news app being<br />>>>> implemented<br />>>>> by Alessandro Cosentino (zimba12). If you want to use background <br />>>>> jobs in<br />>>>> your app, have a look at the apps:newsapp repository first! There <br />>>>> you<br />>>>> will<br />>>>> not only find a working example, but also a strategy of how to <br />>>>> deal with<br />>>>> the<br />>>>> different requirements of AJAX/Webcron and the system cron.<br />>>>> Regards,<br />>>>><br />>>>> Jakob<br />>>>><br />>>>> 1: <a href="http://www.easycron.com">http://www.easycron.com</a>/<br />>>>><hr /><br />>>>> Owncloud mailing list<br />>>>>
Owncloud@kde.org<br />>>>> <a href="https://mail.kde.org/mailman/listinfo/owncloud">https://mail.kde.org/mailman/listinfo/owncloud</a><br />>>><br />>>><hr /><br />>>> Owncloud mailing list<br />>>> Owncloud@kde.org<br />>>> <a href="https://mail.kde.org/mailman/listinfo/owncloud">https://mail.kde.org/mailman/listinfo/owncloud</a><br />>><br />>><br />>><hr /><br />>> Owncloud mailing list<br />>> Owncloud@kde.org<br />>> <a href="https://mail.kde.org/mailman/listinfo/owncloud">https://mail.kde.org/mailman/listinfo/owncloud</a><br /><br /><hr /><br />Owncloud mailing list<br />Owncloud@kde.org<br /><a href="https://mail.kde.org/mailman/listinfo/owncloud">https://mail.kde.org/mailman/listinfo/owncloud</a><br /></pre></blockquote></div></body></html>