It seems we're saying the same thing...
:-)
-Eric
Arnór Heiðar wrote:
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@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@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@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@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@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/