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

Mail-Schnittstelle

Maintainer: Stefan Meretz, Version 2, 29.10.2000
Projekt-Typ:
Status: Archiv

Probleme

(1) Folgendes Problem taucht auf: Die Mailschnittstelle ist eine grundsätzlich offene Schnittstelle. Deswegen wird bei Mailinglisten in der Regel mit Bestätigungen gearbeitet, wenn es um Ein- und Austragen geht.

(2) Solche Bestätigungen sind einfache Replies - dann steht in der Reply-Adresse ein Identifier, der vom Server ausgewertet wird. Oder es handelt sich um ein Kommando im Mailtext (vielleicht auch im Subject), das entsprechend zurückgeschickt werden muss (etwa bei Majordomo) - für viele schon eine grosse Hürde.

(3) Die Alternative ist das Mitschicken eines Passwortes, was zur Befehlsausführung legitimiert. Beispiel hierfür ist auch Majordomo, wo der Admin das Passwort im Mailtext mitschickt.

Konzept-Idee

(4) Diese ganze Problematik steht uns jetzt auch bevor. Ich stelle folgenden Vorschlag zur Debatte - vielleicht hat ja wer eine bessere Idee:

• Kommandos stehen in der Adresse, ggf. mit einem Argument, nämlich dem Projekt, auf das sich das Kommando bezieht
• Weitere Argumente stehen im Mailtext
• Lesende Kommandos werden ohne Bestätigung ausgeführt
• das Kommentar-Kommando wird als einziges ohne Bestätigung ausgeführt
• Alle anderen schreibenden Kommandos erhalten eine Antwort-Mail, die per Reply bestätigt werden muss.

(5) Kommandos haben die Struktur <[command]*[project]@[domain.dom]>, wobei '[command]*' obligatorisch und '[project]' optional ist. Ein Kommando wird also immer von '*' abgeschlossen. Damit ist eine Konfusion mit Projektnamen ausgeschlossen, da '*' in Projektnamen nicht erlaubt sind.

(6) [project] kann nach alter Notation die Form 'proj0000' haben oder nach neuer Notation der Kurzname des Projekts sein (z.B. 'dev' für das Developer-Projekt). Bsp.: <who*proj0011@opentheory.org> oder <who*dev@opentheory.org>.

Kommandos

(7) 1. Lesende Kommandos sind:
1.1 in welchen Projekten bin ich eingetragen: <which*@[domain.dom]>
1.2 wer ist im Projekt eingetragen: <who*[project]@[domain.dom]>

(8) 2. Einziges schreibendes Kommando ohne Bestätigung:
2.1 einen Kommentar schicken: <comment*[project]@[domain.dom]>

(9) 3. Schreibende Mitglieder-Kommandos mit Bestätigung:
3.1 in ein Projekt eintragen: <subscribe*[project]@[domain.dom]>
3.2 aus einem Projekt austragen: <unsubscribe*[project]@[domain.dom]>
3.3 Namen ändern: <setname*@[domain.dom]>
3.4 Optionen setzen: <setoptions*@[domain.dom]>

(10) 4. Schreibende Maintainer-Kommandos mit Argumenten im Mailtext:
4.1 ein Projekt gründen: <new[project]*@[domain.dom]>
4.2 einen Projekttext einreichen: <submit*[project]@[domain.dom]>
4.3 eine neue Version erzeugen: <newversion*[project]@[domain.dom]>
4.4 Maintainerschaft an ein anderes Projektmitglied abgeben: <give*[project]@[domain.dom]>
4.5 Projekt einem anderen als Subprojekt zuordnen: <addsub*[project]@[domain.dom]>
4.6 Mailingliste eines überordneten Projekts verwenden: <uselist*[project]@[domain.dom]>
4.7 Keywords setzen: <keywords*[project]@[domain.dom]>
4.8 Projektitel ändern: <title*[project]@[domain.dom]>
4.9 Projektbeschreibung ändern: <description*[project]@[domain.dom]>

(11) 5. Schreibende Maintainer-Kommandos ohne Argumente:
5.1 Freigabe eines neuen Projektes: <publish*[project]@[domain.dom]>

(12) Das Bestätigungs-Reply hat die Form <confirm000000000*@[domain.dom]>, wobei '000000000' die 9-stellige eindeutige conf_id ist (4-Byte-Unsigned-Int).

Ablauf und Datenstruktur

(13) Der Ablauf ist grob der (Serversicht): Die Mail trifft ein, Kommando wird identifiziert, Argumente werden identifiziert. Ggf. werden Fehlermeldungen erzeugt (falsches Kommando, fehlende Argumente etc.). Die Items werden in zwei Tabellen folgender Struktur eingetragen:
create table confirm (
    memb_id smallint unsigned not null, # member_id
    conf_id int unsigned not null, # confirm_id PK
    send timestamp, # timestamp
    primary key( conf_id )
);
create table confcmds (
    conf_id int unsigned not null, # confirm_id FK
    dbcmd varchar( 16 ), # db command
    cmdkey varchar( 64 ), # command key
    cmdval blob # command value
    key conf_id_idx( conf_id )
);

(14) Zwischen confirm und concmds besteht eine 1:n-Relation, was bedeutet, dass ein oder viele Kommandos mit einer Mail bestätigt werden können. Das ermöglicht prinzipiell eine Syntax wie Stefan Mn. sie vorgeschlagen hat (die Kommandos nicht über die Adressierung identifizieren, sondern komplett im Mailbody). Aber auch die direkt adressierten Kommandos ergeben mitunter mehrere cmdkey-cmdval-Paare.

(15) Beispiel: <setname*@opentheory.org> mit 'Stefan Meretz' im Body könnte folgende Einträge ergeben:
insert into confirm ( memb_id, conf_id ) values( 1, 123456789 );
insert into confcmds values ( 123456789, 'update', '', 'Stefan' );
insert into confcmds values ( 123456789, 'update', '', 'Meretz' );
Antworte ich auf das vorgefertigte Reply <confirm123456789*@opentheory.org>, dann werden die gespeicherten Kommandos ausgeführt.