[Owncloud] Background Jobs

Sun Aug 12 08:35:46 UTC 2012

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 (jfd at owncloud.com)
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 <mail at jakobsack.de> 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 <mail at jakobsack.de> 
> 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 <mail at jakobsack.de> 
>>> 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
>>>> Owncloud at kde.org
>>>> https://mail.kde.org/mailman/listinfo/owncloud
>>>
>>>_____________________________________________

>>> Owncloud mailing list
>>> Owncloud at kde.org
>>> https://mail.kde.org/mailman/listinfo/owncloud
>>
>>
>>_____________________________________________

>> Owncloud mailing list
>> Owncloud at kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud

_____________________________________________

Owncloud mailing list
Owncloud at kde.org
https://mail.kde.org/mailman/listinfo/owncloud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20120812/3612b8c4/attachment.html>