PHP scheduled jobs?

Arnór Heiðar arnorhs at gmail.com
Wed Feb 7 19:57:35 CET 2007


This discussion is going in every direction, so to get some sort of
conclusion in it I would think we should begin by defining a policy
regarding dependencies and so forth with this software.

I'd think that we'd like as many people to use roundcube as possible. To do
this it has to rely on few different software components as possible and the
components it relies on should be very common.

Imap server
Apache / PHP / mysql

All ideas about things running in the background (eg. cron tabs, special
services, even special extensions etc) are all good, but if you make
roundcube depend on stuff like that there are not many people that will be
able to use/install it.

A few software projects have fallen into the trap of making the software to
dependable upon special requirements. Has anybody here tried to install
Horde IMP for an example ? There's a special requirements program that has a
long list of very special extensions and setup requirements which not many
people can both technically set up and/or don't have access to...

Another bad example. Typo3. I actually gave up on this one. Requiring
symbolic links, various php extensions, etc (worst part is probably terrible
documentation)....

I think we should learn from other projects' mistakes and do things proper..

If anybody is experiencing a lot of delay in receiving the mail etc., there
*might* be a bug but most likly the IMAP server of that setup is very very
slow. This is not something roundcube could ever be responsible for.

I think as long as the performance is better than Squirrel (which it already
is) then the performance is not something we need to worry about.

I'd say keeping the design and architecture _clean_ is a big MUST

Who's with me on that ?!? :-)

best w,
Arnor

On 2/7/07, Brennan Stehling <brennan at offwhite.net> wrote:
>
> Yes, it is not exactly a straightforward solution. I would like a more
> modular mail system which would give us more hooks to handle incoming
> mail. I know you can create milters, etc, but those are not a trivial
> thing to build. I once created extensions to the Apache web server
> with mod_perl which was really quite easy and I was able to make
> Apache do something the available extensions could not do alone.  (SSL
> secured reverse proxy with LDAP lookup)
>
> There is the James mail server which was created with Java which I
> believe had plans for plugins.  But I cannot really run Java on my
> FreeBSD 5.x server.
>
> Is there a modular IMAP server which has hooks for languages like
> Perl, Python or Ruby?
>
> Brennan
>
> On 2/7/07, till <klimpong at gmail.com> wrote:
> > I guess you can use just about anything to implement that additional
> > performance layer.
> > Whatever floats your boat.
> >
> > On 2/7/07, Brennan Stehling <brennan at offwhite.net> wrote:
> > > Interesting.  I suppose I could use a Perl script which sits and
> > > listens for notifications and loads data into the MySQL database for
> > > me.  I was hoping to avoid using a server-side language besides PHP
> > > but if PHP is not going to work as a daemon process then Perl seems
> > > like the right alternative.
> > >
> > > Brennan
> > >
> > > On 2/7/07, Mathieu Lecarme <mathieu at garambrogne.net> wrote:
> > > > Brennan Stehling a écrit :
> > > > > I am not terribly familiar with the lastest in PHP.
> > > > >
> > > > > One concept I am considering is a way to keep the state current on
> the
> > > > > server for the webmail user.  Currently the PHP code is only run
> when
> > > > > there is a request, but it would be helpful to have something
> running
> > > > > on the server continually which can respond to events in
> real-time.
> > > > >
> > > > > Here is the idea.
> > > > >
> > > > > A user logs into the system and that updates a timestamp for their
> > > > > date of last activity.  Each time the RC webmail client looks for
> new
> > > > > messages it would update this timestamp.  The service running on
> the
> > > > > server would be away of active sessions and watch their related
> IMAP
> > > > > accounts for new activity.
> > > > >
> > > > > When a new message does arrive it can pull the summary data and
> place
> > > > > it into the MySQL database so that when the webmail client looks
> for
> > > > > an update it can just query the database and not MySQL.
> > > > >
> > > > > And when it does pull the updates from the server it will also
> just
> > > > > hit the database for the summary data and only use the IMAP server
> > > > > when pulling the full message.
> > > > >
> > > > > Has anyone seen PHP run on the server-side continually as a
> service?
> > > > > How would we go about implementing that?
> > > > >
> > > > > Also, what facilities would PHP have to monitor a directory of
> files
> > > > > for updates?  Will it just have to poll the directories and files
> for
> > > > > the last update date?  Since PHP is largely just meant for web
> > > > > applications I doubt it has a file system monitoring feature.
> > > > >
> > > > PHP is not a daemon, it's it secret weapon for managing memory leak
> and
> > > > bad code. Every time a new PHP born, respond and die.
> > > >
> > > > For file monitoring, there is FAM (File Alteration Monitor)
> > > > http://fr2.php.net/manual/en/ref.fam.php
> > > >
> > > > But it's out of scope, IMAP is an abstraction, you can't watch file
> > > > modification, it's IMAP server business, not yours.
> > > >
> > > > IMAP is pull centric, not push. If you wont to do stuff like that,
> Cyrus
> > > > (the most complete IMAP implementation) use notifyd, wich send some
> UDP
> > > > packet when a mail comes, you can listen UDP port in a php script
> (not a
> > > > server one), with a loop and all server stuff wich can put data in
> MySQL
> > > > for its brother, php web.
> > > >
> > > > http://cyrusimap.web.cmu.edu/imapd/man/notifyd.8.html
> > > > http://pwet.fr/man/linux/commandes/zephyr
> > > >
> > > > M.
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Brennan Stehling
> > > http://brennan.offwhite.net/blog/
> > > http://www.smallsharptools.com/
> > >
> > >
> > >
> >
> >
> > --
> > Till Klampaeckel
> > e: mailto:klimpong at gmail.com
> > p: +491704018676
> > l: http://beta.plazes.com/whereis/till
> >
> > Want to know what's up in Berlin?
> > - http://berlin.metblogs.com
> >
>
>
> --
> Brennan Stehling
> http://brennan.offwhite.net/blog/
> http://www.smallsharptools.com/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.roundcube.net/pipermail/dev/attachments/20070207/87c25af6/attachment.html>


More information about the Dev mailing list