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
