[dev] [commits] Horde branch imp_6_1 updated. d6b64567a2a42f722b042bd63024919f8f7c95ec

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> If possible you should still check if you could turn the tasks into  
>> independent Horde_Queue tasks though.
>
> How come?  As long as the Horde_ShutdownRunner instance is  
> guaranteed to run in the Horde environment on the current page, what  
> does it matter? (The ShutdownRunner would never use something like  
> Db storage because that simply doesn't make any sense).
>
> It is much more useful to be able to define a shutdown task without  
> regard to what's *in* the shutdown task - in other words, to allow  
> the shutdown task to be able to altered in the future without  
> worrying about any state being passed to the task.
>
> I understand that the ShutdownRunner doesn't do much right now, but  
> I could see in the future adding something like priority queueing -  
> so that shutdown tasks that MUST happen are run first in case a  
> later queue task crashes the system and prevents the critical tasks  
> from running.

FWIW I don't think any of this makes sense as part of Horde_Queue.  
Horde_Queue is for things that could be done by a distributed queuing  
system like Gearman. By definition, talking to an IMAP server with a  
user's credentials is problematic since we don't usually store user  
passwords for the active system. Anything requiring session state,  
basically, is out. The sweet spot here is things like crawling a  
bookmarked link in Trean, or generating thumbnails in Ansel.

A generic, more featureful shutdown runner seems like a reasonable  
thing to me, but it's different from Horde_Queue.

-chuck