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