progress control (like in update.php)?
Hi, Does anyone working on refactoring the update control out of the update.php script to be reusable in eg. install situations? Are other in need of this functionality? The autolocale module would need this to be able to safely run on a shared host, where it is not possible to set the time limit (and anyway,this is the only way to provide live feedback). As far as I see, any install profile with heavier processing needs would require such a progress feature, so abstracting this out for use by anyone would be nice. Gabor
According to http://drupal.org/node/124727#comment-207879 yched has done a bit of work on it in the hopes of using it with cck. As the issue states, it's also needed for node_access_rebuild(). Off the top of my head it might be good for long-running cron jobs too (in safe mode). -Chris Gabor Hojtsy wrote:
Hi,
Does anyone working on refactoring the update control out of the update.php script to be reusable in eg. install situations? Are other in need of this functionality? The autolocale module would need this to be able to safely run on a shared host, where it is not possible to set the time limit (and anyway,this is the only way to provide live feedback).
As far as I see, any install profile with heavier processing needs would require such a progress feature, so abstracting this out for use by anyone would be nice.
Gabor
On 3/5/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Does anyone working on refactoring the update control out of the update.php script to be reusable in eg. install situations? Are other in need of this functionality? The autolocale module would need this to be able to safely run on a shared host, where it is not possible to set the time limit (and anyway,this is the only way to provide live feedback).
It is already decently abstracted. The upload module uses it. -- Neil Drumm http://delocalizedham.com
Neil Drumm a ecrit le 05/03/2007 23:12:
It is already decently abstracted. The upload module uses it.
Not really. Progress.js is quite generic, and this is what upload.module uses. If you have, say, massive db queries to run (CCK has, for instance, and it seems node acces can't ensure that they won't hit php timeout limit, and can't defer them to cron tasks, you have to basically duplicate a large part of the logic in update.php to have it run in small bits ... The idea is to provide an API for modules to simply define their 'progressive' / 'batch' / 'whatever' operations without having to reinvent update.php.
Borched. Hit 'Send' too soon. This was :
Neil Drumm a ecrit le 05/03/2007 23:12:
It is already decently abstracted. The upload module uses it.
Not really. Progress.js is quite generic, and this is what upload.module uses. If you have, say, massive db queries to run (CCK has, for instance, and it seems node acces rebuild has), and you can't ensure that they won't hit php timeout limit, and can't defer them to cron tasks, you have to basically duplicate a large part of the logic in update.php to have it run in small bits ... The idea is to provide an API for modules to simply define their 'progressive' / 'batch' / 'whatever' operations without having to reinvent update.php.
Yves Chedemois wrote:
Neil Drumm a ecrit le 05/03/2007 23:12:
It is already decently abstracted. The upload module uses it.
Not really. Progress.js is quite generic, and this is what upload.module uses.
If you have, say, massive db queries to run (CCK has, for instance, and it seems node acces rebuild has), and you can't ensure that they won't hit php timeout limit, and can't defer them to cron tasks, you have to basically duplicate a large part of the logic in update.php to have it run in small bits ...
The idea is to provide an API for modules to simply define their 'progressive' / 'batch' / 'whatever' operations without having to reinvent update.php.
Indeed. Importing tens of .PO files in autolocale (which is about to become a core part of Drupal 6 if possible) is another task of this kind. So we should think about abstracting this out on the core level. What about a progress.inc, which is used by update.php and loaded by this heavy lifter modules when need be, but otherwise does not bother Drupal? Gabor
On 06 Mar 2007, at 09:51, Gabor Hojtsy wrote:
What about a progress.inc, which is used by update.php and loaded by this heavy lifter modules when need be, but otherwise does not bother Drupal?
I think this is a sane idea, assuming that the code lends itself to being abstracted elegantly. -- Dries Buytaert :: http://www.buytaert.net/
What about a progress.inc, which is used by update.php and loaded by this heavy lifter modules when need be, but otherwise does not bother Drupal?
Yes! I like the idea, very, very much like. If this gets implemented, I would like to get the ability of outputting some information on each reload so that the user is not left in the dark.
Karoly Negyesi a ecrit le 06/03/2007 11:47:
What about a progress.inc, which is used by update.php and loaded by this heavy lifter modules when need be, but otherwise does not bother Drupal?
Yes! I like the idea, very, very much like. If this gets implemented, I would like to get the ability of outputting some information on each reload so that the user is not left in the dark.
I uploaded the code I have in my sandbox http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/yched/batch/ As I wrote in http://drupal.org/node/124727#comment-207879, it still needs some love and polishing, but the basic functionnality seems ok, so I think it this might be a good dtarting point. I have to leave the keyboard for a few days, and did not have time to - update it for HEAD (it is for drupal 5 currently) - generate a proper patch (having troubles including new files in a patch, ya know...) I'll get to it as soon as I get back. Meanwhile, any feedback/advice/bashing welcome. Yched
(preliminary) patch for D6 : http://drupal.org/node/127539
On 14 Mar 2007, at 00:51, Yves Chedemois wrote:
(preliminary) patch for D6 : http://drupal.org/node/127539
Cool. New features like this can make Drupal a better framework, but we have to figure out a convenient, stable and easy to use API. It would be great if other people could have a careful look at your patch -- challenge the API and the design choices, and figure out whether you'd be able to use this in your modules. There are at least 3 places in core where we could take advantage of this: * Importing translations * Updating your database * An improved cron.php -- I think this would map easily onto Neil's recent task scheduler proposal. Gabor/Goba intends to submit the locale auto-install to core, so maybe you can work with him on that? Thanks for taking this on, Yves. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert a ecrit le 15/03/2007 08:38:
On 14 Mar 2007, at 00:51, Yves Chedemois wrote:
It would be great if other people could have a careful look at your patch -- challenge the API and the design choices, and figure out whether you'd be able to use this in your modules.
Yes, yes, please :-). Some open issues need feedback.
* An improved cron.php -- I think this would map easily onto Neil's recent task scheduler proposal.
Yes, I saw that too. But I'm not sure how update.php-style 'batches' (currently relying on AJAX redirection or <meta http-equiv="Refresh">) could play with cron tasks.
Gabor/Goba intends to submit the locale auto-install to core, so maybe you can work with him on that?
Well, I'm sort of under a deadline right now, and then away from home for a few days, but sure, why not.
participants (6)
-
Chris Kennedy -
Dries Buytaert -
Gabor Hojtsy -
Karoly Negyesi -
Neil Drumm -
Yves Chedemois