php vpopmail daemon etc. - developing story

From: Date: Fri, 02 Apr 2004 13:11:11 +0000
Subject: php vpopmail daemon etc. - developing story
Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-520@lists.php.net to get a copy of this message
Hello everybody, Sorry for cross posting if you get this message two or three times. This is a milestone message and I will not make it a practice. First, thank you everybody who wrote back (all in the CC:). Your comments were great and lead to much better visibility in the situation php <> vpopmail. In this e-mail I make a summary of the situation and propose a direction. Summary ------- Our original goal was to write a php/Smarty/PostgreSQL (the db type is optional) open source mail management module that can allow small (or bigger) dedicated servers to offer mail (qmail/vpopmail/ezmlm) services including billing with super user/domain administrator/mail account owner interfaces that can be used as stand alone or integrated easily in other applications. It is mean to fill in the gap in this technology niche (php/Smarty). qmailadmin does a good job, but does not give tools to the php community - especially to be built into other systems or expanded. More about the project here - http://sourceforge.net/projects/vs-mail-manager/ (the project is very young) However, we hit a bottleneck. The bottleneck -------------- After we researched into the matter we found the bottleneck - the php <> vpopmail communication. The current php vpopmail extension is half dead for a number of reasons, one of the mail - the security issues - Apache must run as the vpopmail user in order for this to work. Looking for solution -------------------- As we do not produce 'private' solutions - we tried to spark a community process on the matter. We talked to more than 20 people and on the two main lists - vpopmail and PECL. We talked to the current php vpopmail extension maintainer James Cox, to one of the original authors Boian Bonev and to one of the current active developers Rick Widmer. We have not escalated the issue to the vpopmail and php maintainers so far. May be this should happen at some point. Our goal is to try to produce a simple and easy to use community supported solution. So far the conclusion is that the interest in the vpopmail extension is far from encouraging. It is used here and there - but all people who use it acknowledge that this is a 'strange' thing. So the answer seems not to be there. Broad series of brainstorming lead to the idea that the solution might be rather in direction of a daemon rather than php extension. This idea was supported by more than ten people from all those who replied. I had a chat with Boian Bonev (one of the original authors of the php vpopmail extension) and he also supports the daemon idea - but he added that it is important to be decided where the daemon will live - in vpopmail, in php or elsewhere (alone). So this is the idea we want to explore now - "php <> vpopmail -> daemon or?" First code ---------- Rick Macdougall has written a daemon for somebody and this somebody has agreed to open the source. This might be a starting point. Waiting from Rick to write back with details. Invitation ---------- In order to avoid fragmented communication I would like to invite everybody interested to join the list vs-mail-manager-daemon on the http://sourceforge.net/projects/vs-mail-manager/ page - we will use this list for temporary initial discussion until we see if there is future in the daemon project. There we can also discuss extension or daemon or triggering (as Marcin Soltysiak suggested) ... After the initial stage we might kill the daemon project or wrap it up and freeze it or develop it - the stage is open. At the end we need clear and simple solution that can be easy to use by the php community. Please, feel free to forward this communication to anybody you think will be interested in the matter. Notice ------ I guess I do not need to say it - but I'll say it - we are not forking anything neither trying to split the development of any project. We try to isolate the case in a neutral environment (as it is a cross-project one), solve the conceptual and community problems and see where is its home. Looking forwards to see you there. Please, note that the list was just created so it might take some hours before it is activated. In order not to miss some of you - I will wait with the first posting about 24 hours. Best, Iavor -- CEE Solutions Ltd. is the brand behind very small technologies and very small media www.verysmall.org

« previous php.pecl.dev (#520) next »