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.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to