Home   Was ist ot ?   Regeln   Mitglieder   Maintainer   Impressum   FAQ/Hilfe  

Mail-Schnittstelle

Maintainer: Stefan Meretz, Version 1, 16.05.2000
Projekt-Typ:
Status: Archiv

(1) PHP ist ein HTML-Seitengenerator, was bedeutet, dass man es eben auch nur dafür einsetzen kann. Soll eine Verarbeitung neben HTTP erfolgen, ist Perl angesagt - nicht gerade meine Stärke.

(2) Es gibt eine Reihe von Funktionen, die zur Zeit nur über das Web benutzt werden können. Theoretisch können alle diese Funktionen auf eine Mailschnittstelle übertragen werden, so dass ot vollständig mailsteuerbar wird. Wie immer gibt's hier viele Möglichkeiten. Die informatische Variante wäre wohl die: Es gibt genau eine Mail-Schnittstelle, sprich eine Adresse. Dort hierein fliessen alle Kommandos, die im Mailbody stehen. Die Kommandos werden geparst, gecheckt und ggf. ausgeführt (die Analogie wäre Majordomo). Die andere Möglichkeit ist, dass ein Teil der Kommando-Steuerung in der Schnittstelle selbst liegt, d.h. der User wählt über die Adresse die Funktion aus (die Analogie wäre ezmlm). Das reduziert die algorithmische Komplexität und ist ggf. für den User einfacher (einfachere Kommandosprache); es ist aber auch weniger flexibel (Power-User!). Im folgenden spiele ich mal eine Idee der zweiten Variante durch.

Welche Funktionen müssen abgebildet werden?

(3)

• a) in ein Projekt eintragen: <subscribe-proj0000@opentheory.org>
• b) aus einem Projekt austragen: <unsubscribe-proj0000@opentheory.org>
• c) wo bin ich eingetragen: <which-project@opentheory.org>
• d) wer ist im Projekt eingetragen: <who-proj0000@opentheory.org>
• e) einen Kommentar schicken: <proj0000@opentheory.org>
• f) ein Projekt gründen: <new-project@opentheory.org>
• g) einen Projekttext einreichen: <submit-proj0000@opentheory.org>
• h) eine neue Version erzeugen: <new-proj0000@opentheory.org>
• i) Freigabe eines neuen Projektes: <publish-proj0000@opentheory.org>
• j) Maintainerschaft an ein anderes Projektmitglied abgeben: <give-proj0000@opentheory.org>
• k) Projekt einem anderen als Subprojekt zuordnen <sub-proj0000@opentheory.org>
• l) Mailingliste eines überordneten Projekts verwenden <maillist-proj0000@opentheory.org>

(4) Hier konzentriere ich mich auf die Funktionen, die sich auf den Projekttext beziehen, also e), f), g) und h). Imho ist das Ziel, sich eine sehr einfache Kommandosprache auszudenken, wobei die Kommentarsprache super einfach sein muss (wenige Befehle), die Maintainersprache etwas komplizierter sein darf. Gut fände ich es, sie an HTML, besser XML zu orientieren. Ich habe nur kaum Ahnung von XML und Bedenken, dass die Syntax zu kompliziert wird z.B. Zwang zu Abschuss-Tags. Ich habe in meinen Beispielen auch Abschluss-Tags verwendet, alternativ sollte auch eine Leerzeile als Abschluss gütig sein (Abschluss-Tag vergessen). Abkürzende Tag gleicher Funktion sollte es geben (z.b. erste drei Buchstaben).

Kommentar schicken (einen bis viele): <proj0000@opentheory.org>

(5) Um einen Kommentar in die Paragraph-Tabelle zu schreiben, müssen die Daten wie folgt ermittelt werden:

• proj_id: aus <proj0000@opentheory.org>
• vers_id: aus metatext mit proj_id und status='act'
• memb_id: mit <absender@domain.dom> select der memb_id aus member, sonst 0
• parastr: aus Para-Kommando (s.u.)
• submit: =now()
• send_by: wenn memb_id>0, dann vorname, nachname aus member mit memb_id; sonst aus Absender ("FakeName" <absender@domain.dom>); Zeit aus submit; Format: DD.MM.YYYY, HH:MM, <a href="mailto:absender@domain.dom">[Vorname Nachname | FakeName]</a>
• headln: aus Headln-Kommando (s.u.)
• text: aus Kommentar-Kommando

Kommandos

(6)

• Para-Kommando (z.B. <AbsatzNr>(0.0.0)</>): Das Kommando verweist auf den zu kommentierenden Absatz (resp. seine Nummer). Schon mitdenken: Ausweitung auf einzelne Sätze im Absatz.
• Headln-Kommando (z.B. <Betreff>...</>): wenn leer, dann Re: headln aus kommentiertem Absatz; wenn leer, dann default z.B. wie bisher "Kommentar zu Abs. (0.0.0)"
• Kommentar-Kommando (z.B. <Kommentar>...</>): aus Mailbody ohne Footer falls kein Ende-Tag

Ablauf

(7)

• Die Mail geht über <proj0000@opentheory.org> ein, Attachments abtrennen.
• Die proj_id wird daraus ermittelt.
• Check, ob das Projekt existiert und aktiv ist (select vers_id mit status='act'); wenn nicht, Reply mit Fehlermeldung an Absender, Ende.
• Ermitteln von Vorname, Nachname mit <absender@domain.dom>. Nicht gefunden, dann "FakeName" aus E-Mail-Absender. Nicht vorhanden, dann E-Mail-Absender.
• Kommando-Wert-Paare aus Mail-Body ermitteln und in Hash schreiben
• Nun nur noch auf Hash arbeiten
• Erstes Para-Kommando suchen, keins da, Fehler-Reply, Ende.
• Solange Para-Kommando:
  • Lesen Para-Kommando: parastr ermitteln,
  • kommentierten Abs. aus DB lesen, nicht vorhanden, Fehler-Reply, Ende.
  • Lesen Headln-Kommando: headln ermitteln.
  • send_by zusammenbasteln.
  • Lesen Komentar-Kommando: Text ermitteln. Nix drin, Fehler-Reply, Ende.
  • Kommentar Datensatz in DB schreiben.
  • Kommentierten Absatz und Kommentar in Puffer
• Mail an das Projekt mit Puffer schicken. Fertig.

Projekt gründen (genau eines): <new-project@opentheory.org>

(8) Um ein neues Projekt in der Metatext-Tabelle anzulegen, müssen die Daten wie folgt ermittelt werden:

• proj_id: neue Id generieren
• vers_id: =1
• memb_id: mit <absender@domain.dom> select der memb_id aus member
• title: aus Titel-Kommando (s.u.)
• titlabb: aus Titel-Abk-Kommando (s.u.)
• submit: =now()
• status: ='ini'
• ref_by: =0
• maillst: eigene Mailingliste aus proj_id und titlabb, Format: "Projekt titlabb" <proj0000@opentheory.org>
• link: =""
• descr: aus Description-Kommando (s.u.)

Kommandos

(9)

• Titel-Kommando (z.B. <Titel>...</>): Der Titel
• Titel-Abk-Kommando (z.B. <Kurztitel>...</>): Der Kurztitel
• Description-Kommando (z.B. <Beschreibung>...</>): Die Projekt-Beschreibung

Ablauf

(10)

• Die Mail geht über <new-project@opentheory.org> ein, Attachments abtrennen.
• Ermitteln von Vorname, Nachname, memb_id mit <absender@domain.dom>. Nicht gefunden, dann Fehler-Reply.
• Kommando-Wert-Paare aus Mail-Body ermitteln und in Hash schreiben
• Lesen Titel-Abk-Kommando, leer, Fehler-Reply, Ende
• Lesen Titel-Kommando, leer, Fehler-Reply, Ende
• Lesen Description-Kommando, leer, Fehler-Reply, Ende
• Check, ob gleichnamiges Projekt existiert,
  • wenn ja, und status='ini' dann vorhandenen metatext und projmemb löschen
  • wenn ja, und status='act', Fehler-Reply mit Hinweis auf <new-proj0000>, Ende
  • wenn ja, und status=('arc' oder 'fin'), Fehler-Reply, Ende
• Die proj_id wird generiert.
• Datensatz in metatext schreiben (Konstanten s.o.)
• Absender als erstes Mitglied eintragen: proj_id und memb_id in projmemb
• Mail an Absender schicken, Beschreibung des nächsten Schrittes (Text einreichen). Fertig.

Projekttext einreichen: <submit-proj0000@opentheory.org>

(11) Um einen kompletten Projekttext in die Paragraph-Tabelle zu schreiben, müssen die Daten wie folgt ermittelt werden:

• proj_id: aus <submit-proj0000@opentheory.org>
• vers_id: aus metatext mit proj_id und status='act'
• memb_id: mit <absender@domain.dom> select der memb_id aus member: muss übereinstimmen mit memb_id aus metatext, sonst Fehler-Reply.
• parastr: aus Para-Kommando (s.u.)
• submit: =now()
• send_by: =""
• headln: aus Headln-Kommando (s.u.)
• text: aus Text-Kommando

Kommandos

(12)

• Para-Kommando (z.B. <AbsatzNr></>): Das Kommando erzeugt eine neue Absatz-Nummer.
• Headln-Kommando (z.B. <Ueberschrift>...</>): wenn leer, dann ""
• Text-Kommando (z.B. <Text>...</>): aus Mailbody ohne Footer falls kein Ende-Tag

Ablauf

(13)

• Die Mail geht über <proj0000@opentheory.org> ein, Attachments abtrennen.
• Die proj_id wird daraus ermittelt.
• Ermitteln von Vorname, Nachname, memb_id mit <absender@domain.dom>. Nicht gefunden, dann Fehler-Reply.
• Check, ob das Projekt existiert und neu ist (select vers_id mit status='ini'); wenn nicht, Reply mit Fehlermeldung an Absender, Ende.
• Kommando-Wert-Paare aus Mail-Body ermitteln und in Hash schreiben; dabei Leerzeilen durch Para-Kommando ersetzen, wenn keins vorhanden
• Nun nur noch auf Hash arbeiten
• Erstes Para-Kommando suchen, keins da, Fehler-Reply, Ende.
• Erstes Text-Kommando: Nix drin, Fehler-Reply, Ende.
• Alle Absätze löschen mit proj_id, vers_id
• Solange Para-Kommando:
  • Lesen Para-Kommando: parastr ermitteln,
  • Lesen Headln-Kommando: headln ermitteln.
  • Lesen Text-Kommando: Text ermitteln.
  • Text Datensatz in DB schreiben.
• Link erzeugen, update metatext
• Mail an Maintainer schicken mit Vorschau-Link und Reply=<publish-proj0000@opentheory.org>. Fertig.

Neue Version erzeugen: <new-proj0000@opentheory.org>

(14) Um eine neue Version eines vorhandenen Projektes in der Metatext-Tabelle anzulegen, müssen die Daten wie folgt ermittelt werden:

• proj_id: aus <new-proj0000@opentheory.org>
• vers_id: vers_id von status='act' plus eins
• memb_id: mit <absender@domain.dom> select der memb_id aus member
• title: aus Titel-Kommando (s.u.)
• titlabb: aus metatext mit proj_id
• submit: =now()
• status: ='ini'
• ref_by: aus metatext mit proj_id
• maillst: aus metatext mit proj_id
• link: =""
• descr: aus Description-Kommando (s.u.)

Kommandos

(15)

• Titel-Kommando (z.B. <Titel>...</>): Der Titel
• Titel-Abk-Kommando (z.B. <Kurztitel>...</>): Der Kurztitel
• Description-Kommando (z.B. <Beschreibung>...</>): Die Projekt-Beschreibung

Ablauf

(16)

• Die Mail geht über <new-proj0000@opentheory.org> ein, Attachments abtrennen.
• Die proj_id wird daraus ermittelt.
• Ermitteln von Vorname, Nachname, memb_id mit <absender@domain.dom>. Nicht gefunden, dann Fehler-Reply.
• Kommando-Wert-Paare aus Mail-Body ermitteln und in Hash schreiben
• Lesen Titel-Abk-Kommando, leer, Fehler-Reply, Ende
• Lesen Titel-Kommando, leer, Fehler-Reply, Ende
• Lesen Description-Kommando, leer, Fehler-Reply, Ende
• Check, ob gleichnamiges Projekt existiert,
  • wenn ja, und status='ini' dann vorhandenen metatext u. projmemb löschen
  • wenn ja, und status=('arc' oder 'fin') dann Fehler-Reply, Ende
• Datensatz in metatext schreiben (Konstanten s.o.)
• Absender als erstes Mitglied eintragen: proj_id und memb_id in projmemb
• Mail an Absender schicken, Beschreibung des nächsten Schrittes (Text einreichen). Fertig.

Was fällt auf?

(17) Es geht um die Nachbildung von Funktionen, die bereits über die Webschnittstelle verfügbar sind. Die Web-Schnittstelle ist in PHP realisiert, die Mail-Schnittstelle ggf. nun in Perl. Doppelte Arbeit, doppelter Pflegeaufwand, doppelte Bug-Wahrscheinlichkeit. Stellt sich also grundsätzlicher die Frage, ob wir uns nicht auf eine funktionale Basis, auf einen Code für die gleichen Funktionen, beschränken können. Was für ein Frage, nur welche? Kommt euch das naiv vor? Ich bin halt so langsam.