@Jakob: maybe I am missing something here, but is there a way for the app developer to specify how often the job is executed?
Thanks, Alessandro On Mon, Aug 13, 2012 at 9:50 AM, Klaas Freitag <[email protected]> wrote: > On 13.08.2012 16:23, Jakob Sack wrote: >> >> Hi Klaas, >> >> maybe I chose the wrong words: To disable background jobs you do not >> have to edit the program code but you must set the appconfig value >> core:backgroundjobs_mode to "none". > > Ah, ok, sorry... > > IMO the important point is that an update does not kick out such things, but > you probably have taken care :) > > Thanks, > > Klaas > > >> >> Am 13.08.2012 11:49, schrieb Klaas Freitag: >>> >>> On 12.08.2012 11:29, Jakob Sack wrote: >>>> >>>> I removed the option from the UI. In the program code the option "none" >>>> is still usable. >>> >>> Come on, isn't that the worst of all possible solutions? ;-) >>> >>> Changing the program code is not the best way to do app configuration >>> as the change will be gone with the next update. Why not put an value >>> in config.php if we do not want a GUI option? >>> >>> I think there should be an option to set up ownCloud completely stand >>> alone, without having the system seeking out for other web services. >>> >>> Or do I get something wrong? >>> >>> Thx, >>> Klaas >>> >>>> >>>> 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 >> >> >> _______________________________________________ >> 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
