<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi all,<div><br class="webkit-block-placeholder"></div><div>Unfortunately I didn't arrive on time for the meeting. I wanted to give my 2 cents to Horde Board, but since I missed the meeting I'll post them here.</div><div><br class="webkit-block-placeholder"></div><div>Following the meeting's agenda, first an introduction.</div><div><br class="webkit-block-placeholder"></div><div>For those who don't know me, I'm Nuno Loureiro (MrVi on IRC, the only zombie there) and I work for Portugal Telecom / SAPO. I actually started using IMP on the very first version (around 1998?) and I have been a very sporadic contributor to the project (code-wise). </div><div><br class="webkit-block-placeholder"></div><div>For the last few years I've been contributing in a different way though. DIMP for example, is a result of a SAPO project leaded by me on PT's side and developed by some of the Horde Core Developers. Since we gave the entire project back to the community, we (SAPO and Horde) try to mutually agree on the roadmap of the project, even though SAPO has some special needs.</div><div><br class="webkit-block-placeholder"></div><div>For those who don't know SAPO, SAPO is the Portugal Telecom's ISP. We have around 5M email accounts (1M active) and around 6,000 simultaneous sessions on the Webmail.</div><div><br class="webkit-block-placeholder"></div><div>Back to the important stuff, I'm happy with the main goals for the project that were mentioned in the meeting. I strongly agree with the following things discussed in the meeting:</div><div>- making Horde as a developer framework, instead of a groupware project;</div><div>- get rid of Horde_Template (my opinion about this - <a href="http://blog.sig9.net/2008/01/21/template-engines/">http://blog.sig9.net/2008/01/21/template-engines/</a>) and DataTree (oh yeah);</div><div>- promoting Horde. That's common sense, people must know about Horde in order to use it. I guess that once you make Horde as a developer framework instead of a groupware project it will attract more developers that don't use Horde because they think of Horde as an application instead of a framework. Developer conferences like OSCON or PHP Conference are good places to promote Horde. Good documentation and the use of hype technologies (ajax, openid, Oauth) as well. IMHO, it would be very important to have an excellent documentation repository, of every single package, much like <a href="http://dev.horde.org/routes/">http://dev.horde.org/routes/</a>.</div><div><br class="webkit-block-placeholder"></div><div>Now, my contribution on what I would like the Horde (as a project) to be. </div><div><br class="webkit-block-placeholder"></div><div>I know I have specific needs. Horde applications are very flexible (lots of conditions to match the admin's settings and setup) and of course that has its weight performance-wise. What I mean is that I could reduce a *lot* of code to match my setup, but I understand it's necessary since the project is not targeted to ISP's.</div><div><br class="webkit-block-placeholder"></div><div>So, let's try to itemize the things that I would like to be included in the project's roadmap:</div><div><br class="webkit-block-placeholder"></div><div>- Performance improvements: the most important thing for us is performance related . It's getting better and better but of course there's still some work to be done. I can announce in advance for those who don't know yet, that we are developing a new IMAP PHP module (not c-client based) which goal is to use IMAP in a **much more efficient way**. I hope that will give a huge step forward on IMP/DIMP's performance. Actually a pre-alpha version of the module is already done and Michael Slusarz (hi!) will come here in 2 weeks to start working on an IMP/DIMP driver for the new module, or at least to abstract the IMAP code.</div><div><br class="webkit-block-placeholder"></div><div>- With DIMP, I guess a new type of Horde applications was born. The typical set of applications for a Webmail are Mail, Contacts and Calendar. It might be a good idea to package all these 3 applications as one and have them to look like one application only (in terms of UI). Right now, only DIMP is ready for this set, but soon we'll be able to add the Calendars too (born from another SAPO project). Note that one important thing here is to have the entire set as one application (UI-wise). Right now, we have hacks to include calendar and contacts (and preferences?) in a DIMP setup, which doesn't look great.</div><div><br class="webkit-block-placeholder"></div><div>- Virtualhosts: I can bet a lot of installations (ISPs, Hosting companies) need to have multiple Webmail layouts (maybe with a different logo and colors) based on the host used (URL). That might need different configuration files, different templates, different css, different graphics. I still think that the most practical way to achieve this is to have a different directory per VH with templates, css, graphics and configs inside. One thing for this to work flawlessly is to take out HTML (or layout) code from the framework packages or core scripts, basically to follow a MVC model. One example of that is Horde_Form.</div><div><br class="webkit-block-placeholder"></div><div>- Usability issues, again for IMP/DIMP: to reply/forward messages with the HTML Editor doesn't really work as expected; the new mime lib to abstract unnamed parts. Overall, there are a lot of information provided to the user that makes sense for us, advanced users, but confuses the newbies.