On Thu, 2010-02-11 at 08:26 +0000, Jochem Maas wrote: > if you're doing all this already in order to facilitate a multi-platform > install ... why not go the extra yard and have the install process setup > a cronjob (or scheduled task, launchd entry, etc, depending on platform)? The reason is that the php application will not only be installed locally, but also properly on a server. And some users could have servers that do not offer access to the cron daemon. Which means it might be covered by the installer on windows, and other platforms, but there would still be no crontab equivalent on the server that runs on the internet. Hence an platform-independent solution is still needed. Once that platform-independent solution is there, it could as well be deployed everywhere. But this seems to be going off-topic. > I have recently been using daemontools (*nix/bsd compatible daemon management > tools ... also used to manage qmail processes) to actually keep a > long running / perpetual script running ... it's a very robust bit of If little or no configuration would be required that would help, and if it were available on commodity servers like Bravehost that would be a plus too. > it's merely the vehicle your using to have the script run > perpetually that irks me. Well, on the type of vehicle used to get a job done, my feeling is that PHP is very flexible and should / can adapt to the user's need, so why not use the tools provided? > > in practice not much on a personal machine - nonetheless it's wasteful > and technically a webserver is unneeded and creates another layer of > complexity and overhead. it does seem rather brittle in terms of how you > have it set up though. Basically it is written as a web application, which installs locally as well. Therefore to reduce programming efforts, and to make it easier to be cross-platform, the LAMP server was chosen. Programmer's efforts are expensive, therefore choosing these robust tools as Apache, MySQL and PHP / Perl / Python was done for that reason. > > it's possible that it's the best you can do given the pratical circumstances > of the users/maintainers of the installations ... but I hazard to say > you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optimal > setup ... then again it's rather hard to say without known exactly what you > want done every minute, why it needs to be done on the user's machine and > what the connection with a cloud. The "cloud" comes in when somebody installs the app in such an environment (if that is at all possible, I haven't looked into that). The tasks to be done every minute is to check incoming email and process is since users can operate the system through email as well must like a message board where users can post by email. Then there's the processing of the outgoing email queue since all "email" sent to a user is first going to be put online, then transferred to email if the connection is on. Then there would be regular tasks as sending out diffs to the users since this is an online collaboration environment for translators, so other members can see who changed what in the translation. (This all is still to be made, but these are the plans). PHP is very flexible so should be able to do all of this. But I am afraid to go off-topic again. Teus. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
