Avoid using cron for automated updates. about storytlr HOT 7 OPEN

Would we store the last run as a property I assume?
What's the best way to start that processing in the background?

from storytlr.

Yes, I advocate using properties as much as possible to avoid adding fields to the schema. It may also be worth one day to add a system_properties table for global settings.

In this case however, we can reuse these two fields in the user table:
http://github.com/storytlr/core/blob/master/protected/install/database/schema/core.sql#L451

Or this one in the source table:
http://github.com/storytlr/core/blob/master/protected/install/database/schema/core.sql#L286

The trick will be to be smart enough to avoid triggering multiple updates in paralell. The updates themselves could be a fork to execute the update.php script using exec ?
http://php.net/manual/en/function.exec.php

from storytlr.

I agree with all that, except that some shared hosts run suhosin with the exec family of commands disabled. Should the workaround for that just be "well, then use cron." ?

Any other options? How about a long-poll type XHR?

from storytlr.

Indeed, and since we want to solve the issue exactly for these kind of users, we may need to find other ways. There is also the PHP process functions, on top of which the PHP Multi-threading package is built: http://be.php.net/pcntl_fork - I have never played with this.

Another easier trick may be indeed to add something like <script href="/update"/> at the end of the page. The browser will try to load the script, triggering an update. If content is updated, the script may even trigger a notification to invite the user to refresh the page. We could also trigger the updates from storytlr.org: upon installation the storytlr ping home (may also be interesting to do just to keep track of deployments, versions, etc.) and requests that we trigger updates. Then, from storytlr.org, we ping individual storytlrs on their update url.

It seems possible to avoid threading and forking, which is probably a better option indeed.

from storytlr.

I like the option of the remote trigger personally. Thinking about the script inclusion some more I see potential for harm. If we didn't protect it from spamming properly it would be easy to use that as a DOS attack. It seems like the storytlr.org trigger would be easier to implement too, until all of your bandwidth is absorbed sending out GET's :-)

Either way, I think an optional installer reporting tool would be nice for us.

from storytlr.

Well, in both case we'll need the server to be smart enough and not update unless it is required (and avoid updating while another update is already ongoing). The script hack is worth a try. I have opened another issue for the reporting feature (issue 15).

from storytlr.

Don't forget that the update should be started after the page is loaded or at least at the end of script execution to minimize disruptions to the user experience.

from storytlr.