Project: Webinterface II - 07. Lastreadpointers und Hashes
From: Ulrich Schroeter (30.6.04)
- [77] R24-077-FUTURE4FIDO.GER (2:244/1120) ----------------- FUTURE4FIDO.GER -
Msg : #1767 [923] -1759 Snt Loc
By : Ulrich Schroeter 2:244/1120 Mit 30 Jun 04 06:50
To : Kai Richter
Subj : Multiple-Hash-Thread-Read-Index Relations (war: Neues Projekt)
-------------------------------------------------------------------------------
moin Kai,
Tuesday June 29 2004 14:05, you wrote to me:
KR> Tag Ulrich!
KR> Am 28 Jun 04, Ulrich Schroeter schrieb an Kai Richter:
KR>>> Die alt Msgbase soll doch die Msgbase sein die auch von der
KR>>> Web-BBS benutzt werden soll. Ich sehe nur die
KR>>> Multi-Lastread-Pointer welche zwischen der Web-BBS und
KR>>> klassischen BBS syncronisiert werden müssten.
US>> das sind die 2 Parts die Synchronisiert werden muessen. Jawohl.
KR> Ich sehe keine Notwendigkeit für die Syncronisation.
ok, du willst es wohl ganz genau wissen ....
neben dem Webinterface koennen rein prinzipiell noch 10 andere
Tools Msgbase Operationen durchfuehren.
Die Msgbase Operationen im einzelnen:
1. add new message
2. read message
3. change message
4. delete message
5. renumber message
Fuer einen Multiple-Hash-Thread-Readpointer-Index spielt zum Beispiel das
einfache hinzufuegen einer neuen Mail (1.) keine Rolle, da die neue
Nachricht ja noch nicht gelesen wurde ... dahingehend stimme ich dir zu.
1. add new message (-)
Sehr wohl aber veraendert eine Read-Operation fuer einen User
diesen Pointer ...
Gestern war ich unterwegs und habe ueber das Webinterface die Mails
gelesen, die ich heute, wo ich zu Hause bin und mit Golded arbeite
die Mails nicht noch einmal wiederlesen moechte, sondern da weitermachen
wo ich gestern im Interface aufgehoert habe. Ebenso moechte ich morgen,
wenn ich wieder unterwegs bin, die Mails, die ich heute mit Golded
alle abgearbeitet habe, nicht wieder im Webinterface als ungelesen
angezeigt zu bekommen ...
Variiere fuer die Golded Komponente mit einem NNTP-reader, Telnet-BBS
und anderen Tools, die Userbasierend "Sichten" veraendern
2. read message (+)
Change Msg .... bei genauerer Ueberlegung wird diese Operation wohl
eher selten bis garnicht vorkommen ... Wenn Aenderung, dann kann
zwar _alles_ an einer Msg veraendert werden, aber die MsgID bleibt
sicherlich trotzdem erhalten. Allenfalls, dass hier der "Gelesen"
Status zurueckgesetzt werden muesste auf "ungelesen" ....
Fuer die allgemeine Betrachtung ist dieses Szenario aber eher unwahr-
scheinlich. Also eher, diesen Fall ignorieren.
3. change message (-)
Sehr wohl hat eine Loeschoperation Auswirkungen auf einen
Multiple-Hash-Readpointer-Index .... egal von welchen Tool
diese Loeschoperation durchgefuehrt wird (Userbasierend, Maintenance).
Wenn bei Loeschoperationen nicht die Hash-Pointer aus den Listen
entfernt werden, wachsen die Listen ins unendliche ....
also muss hier aufgeraeumt werden, egal wie.
Den hash-Index komplett auf Null zurueckzusetzen ist keine
Option. Man will ja die bereits gelesenen Mails gefiltert
sehen. Eine Operations-nahe Aktuallisierung des Hash-Index
waere wuenschenswert. Beim Loeschen einer Nachricht die Msgid
merken, alle Hash-Indizes aller User nach dieser ID durchsuchen
und entfernen. Wird aber nicht von saemtlichen "beteiligten"
"Msgbase-modifizierenden" Programmen unterstuetzt. Also muesste
hier eine "nachgelagerte" Maintenance durchgefuehrt werden.
Sofern ein Programm ein Flag setzen kann, wenn eine Msg geloescht
wird koennte man die Maintenance antriggern ... oder man fuehrt
die Maintenance in regelmaessigen Abstaenden durch (i.e. daily maintenance).
Dazu muessten aber _alle_ Hash-Indizes komplett durchgeackert werden
um festzustellen, welche Hash-Werte fehlen, also nicht mehr in der
Msgbase existieren, damit diese dann auch entfernt werden koennen.
4. delete message (+)
Eine Message Renumbering Operation hat wohl weit weniger Einfluss
auf die MsgIDs. Daher braucht diese Operation nicht beruecksichtigt
werden.
5. renumber message (-)
Fassen wir zusammen:
Bei der Veraenderung des Msgbase Inhalts durch die Operationen:
2. read message (+)
und 4. delete message (+)
werden die Hash-Indizes zunaechst einmal inhaltlich "veraendert".
Im Fall 4. delete messages reicht sicherlich eine daily maintenance
aus um die Hash-Indizes zu aktuallisieren. Im Falle von Punkt
2. read messages, reicht die daily maintenance sicherlich nicht
mehr aus. Hier waere eine Aktuallisierung zeitnah an der Veraenderung
wuenschenswert ... Hier waere aber eine "vereinfachte", userbezogene
Maintenance moeglich, sofern sich feststellen liesse, welcher "User"
hier eine Msgbase Operation durchgefuehrt hat....
Da die wenigsten Tools zurueckmelden, dass eine Msg gelesen
wurde oder geloescht wurde, allenfalls das eine neue Netmail
oder Echomail geschrieben wurde, waere hier jedesmal nachdem
ein Tool auf die Msgbase zugegriffen hat solch eine "userbezogene"
Maintenance durchzufuehren, sozusagen prophylaktisch.
Daraus ergeben sich nun im wesentlichen 2 Fragen:
a) laesst sich in irgendeiner Form im Nachhinein (nach einem Toolzugriff
auf die MsgBase) feststellen, auf welchen User sich die Msgbase
Operation bezog oder andersherum, welcher User hat auf die
Msgbase zugegriffen?
b) ist in irgendeiner Form im Nachhinein nachvollziehbar, welche Msgs
dieser User gelesen hat?
Frage b) laesst sich sicherlich einfacher beantworten:
Zu b) laesst sich allenfalls anhand der eindimensionalen
Lastreadpointer bestimmen, bis wohin ein User ein Echo "gelesen"
hat oder "gesprungen" ist - ich blaettere in einem Echo mitunter
auch nur in der Uebersicht ans Ende aller Nachrichten, ohne dass
ich jede einzelne Nachricht lese und positioniere damit den Lastread-
pointer ans Ende aller Nachrichten eines Echoes. Aus der
Multiple-Thread Sicht habe ich aber diese Nachrichten uebersprungen
und nicht gelesen ...
Ich lasse diese Punkte jetzt mal hier offen im Raum stehen.
Vielleicht das Volker hier noch ein paar Gedanken dazuliefern
kann, da er bisher mit Multiple-Hash-Thread-Pointern uebers
Webinterface vielleicht einige Erfahrungen gesammelt hat ... ,-)
regards, uli ;-)
---
* Origin: AMBROSIA - 63067 Offenbach/M. (2:244/1120)
