On Thu, Feb 11, 2010 at 8:47 AM, Teus Benschop <teusjannette@xxxxxxxxx> wrote: > 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 > > Could the app be converted to an Adobe AIR app or use PHPdock ( http://www.nusphere.com/products/phpdock.htm ) to run local? There are a number of security issues that surround installing a webserver and a database locally on a users machine that may become issues. -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
