Channel Datenbanken

Die Diskussion um ein Proposal für den Einsatz von E_STRICT dominierte die PEAR-Dev-Mailingliste für geraume Zeit und führte zu einigen interessanten Erkenntnissen. Nach Abschluss der Diskussion ging ich erst einmal in den Urlaub, in dem ich mich mit Mail_Mbox näher beschäftigte.

E_STRICT?
Eigentlich ist E_STRICT eine clevere Hilfe für Entwickler: Wenn die Option in der php.ini bei error_reporting mit angegeben wird, erscheint ein Hinweis, wenn eine Funktion benutzt wird, die in späteren Versionen herausfliegen wird bzw. soll.
In einem Proposal wurde nun vorgeschlagen, dass neue Packages bei eingeschaltetem E_STRICT ohne Warnung durchlaufen müssen (E_STRICT compliance).
Die Diskussion drehte sich um zwei Punkte: Erstens um die Frage, ob und ab wann neue Packages nur noch unter PHP 5 lauffähig sein müssen. Und zweitens, ob E_STRICT überhaupt einen Qualitätsbeitrag darstellt.

Nur noch PHP 5?
Alt ist die Diskussion über Packages, die PHP 5 voraussetzen. Allerdings gab es eine Verschiebung im Vergleich zu früheren Diskussionen: Es deutet sich eine Bereitschaft an, ab einem gewissen Datum PHP 4 nicht mehr explizit zu unterstützen. Als heißer Kandidat gilt Januar 2007.
Bis dahin gilt es durchaus noch einige Fragen zu klären, z.B. ob die Fehlerbehandlung per PEAR_Error nicht durch eine Variante ersetzt werden soll, die auf Exceptions setzt.

E_STRICT compliance?
Das Problem PHP 4 vs. PHP 5 wird sich mehr oder weniger mit der Zeit lösen. So einfach ist das mit E_STRICT leider nicht. Während der Diskussion wurde klar, das E_STRICT kein gutes Qualitätsinstrument ist: Erstens sind die Aussagen von E_STRICT nicht in Stein gemeißelt und vor allem keine Einbahnstraße. Es ist möglich, dass der gleiche Code für PHP 5.1 in Ordnung ist, bei 5.2 aber eine Warnung wirft und bei 5.3 wieder anstandslos durchläuft. Zweitens, E_STRICT-Änderungen können sich bereits bei PHP-Patches ergeben, z.B. von PHP 5.x.2 auf PHP 5.x.3. Package-Entwickler wären unter Umständen gezwungen, mit jedem Mini-PHP-Release auch ihre Packages zu überarbeiten.

Webmailer@home
Eigentlich mag ich Webmailer à la Web.de & Gmail nicht. Klassische E-Mail-Clients sind einfach komfortabler. Der einzige Vorteil von Weboberflächen ist, dass man in jedem Internet-Cafe auf seine E-Mails zugreifen kann. Im Urlaub fragte ich mich, warum E-Mail-Clients eigentlich keinen Webzugriff anbieten, um auf die E-Mails auf dem eigenem Rechner zugreifen zu können. Statt aber nun einen Feature-Request zu schreiben, lief mir das Package Mail_Mbox über den Weg.
Viele Mailprogramme unter Unix, aber auch Thunderbird, speichern E-Mails im Mbox-Format: einem Text-Format; für jedes Postfach bzw. E-Mail-Ordner wird eine eigene Datei angelegt. Das Package bietet Methoden, um auf E-Mails in einer solchen Datei zuzugreifen, einzufügen, zu ändern oder zu löschen.
Zuerst wird ein neues Objekt erzeugt und der Name der Mbox-Datei übergeben. Der Ort und der Name der Datei sind abhängig vom E-Mail-Programm. Thunderbird benennt die Datei entsprechend dem Namen des E-Mail-Ordners. Im nächsten Schritt wird die Datei geöffnet; liefert die Methode open() einen Fehler zurück, dann konnte die Datei nicht geöffnet werden. Beachten Sie, dass einige E-Mail-Programme die Datei meist exklusiv sperren. Deshalb sollte das E-Mail-Programm nicht laufen, wenn das eigene Skript auf die Datei zugreift.
Um eine E-Mail zu erhalten, rufen wir get() auf. Als Parameter übergeben wir die Positionsnummer der E-Mail in der Datei. Allerdings erhalten wir die E-Mail so, wie sie auch in der Datei steht, sprich mit allen Headern. Diese Daten können wir über Mail_Mime in eine strukturierte Form bringen. In Listing 1 wird demonstriert, wie man die Betreff-Zeilen aller E-Mails eines Ordners ausgibt.

Listing 1

  -----------------------------------------------------------------------

  <?php
  require_once  'Mail/MBox.php';
  require_once  'Mail/mimeDecode.php';
['include_bodies']  = true;
  ['decode_bodies']  = true;
  ['decode_headers']  = true;
  ['crlf']           = "\r\n";
 = new  Mail_MBox('/pfad/MeineEmails');
  if(!PEAR::isError(->open()))  {
    for(=0; <->size(); ++) {
      ['input'] = ->get();
       =  Mail_mimeDecode::decode();
      echo  ->headers['subject']."\n";
    }
    ->close();
  } else {
    echo 'Konnte die  Mailbox-Datei nicht öffnen!';
  }
  ?>

Für den Zugriff auf die eigenen E-Mails eine Weboberfläche zu schreiben, stellt mit den beiden Packages nur noch eine Fleißaufgabe dar. Wenn man nicht auf dem eigenen Rechner einen öffentlichen Webserver betreiben will, dann lassen Sie Ihre private Weboberfläche bei einem Hoster laufen. Allerdings nicht vergessen, vor Urlaubsantritt die notwendigen Dateien hochzuladen und einen Passwortschutz zu integrieren!

Alexander Merz ist Herausgeber des PEAR-Manuals. Sie erreichen ihn unter kontakt[at]alexander-merz.com.