Joachim Merkel <[EMAIL PROTECTED]> wrote on 26.06.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
> ["X-XP-Box"]
>> Augenscheinlich ist das ein Nachtragsfix f�r die umfangreichen
>> �nderungen zum Thema "forcebox" vom 24.04.2002, deren Dokumentation
>> f�r sich genommen schon nicht alle Szenarien vollst�ndig beschreibt
>> (weil viel zu viele).
> Das ist insofern f�r mich eine neuer Ansporn, mich auch mal
> wieder mit forcebox zu befassen, das war ja seinerzeit eine
> Riesengeschichte. Mir ist dabei n�mlich vor kurzem gelungen
> eine Nachricht komplett zu verhunzen, mal sehen, ob ich das
> reproduzieren kann.
Ok, la� h�ren.
>> Erst sp�ter habe ich mich nochmal dieses Themas angenommen und selbst
>> weitere umfassende �nderungen vorgenommen, die aber noch nicht fertig
>> und daher auch noch nicht committet sind.
> Das ist mir auch noch in Erinnerung, da� es nur vorl�ufig
> abgeschlossen wurde.
Zum Zeitpunkt des urspr�nglichen forcebox-Commits hatten wir schon
gedacht, alles erschlagen zu haben.
Was aber seinerzeit �berhaupt nicht bedacht und getestet wurde, waren
z.B. Dinge wie Verteiler (die User mit adre�-inkompatiblen Netztypen
enthalten k�nnen) und Antworten auf Postings mit Followup-To:-Header,
bei denen XP sog. "Phantom-Server" erzeugt bzw. verwendet.
Beides extrem aufwendig in den Griff zu kriegen, da habe ich schon
seitenweise Routinen komplett neu geschrieben. Das betrifft nicht nur
forcebox, sondern das gesamte Handling von Followup-To: und Verteilern
an sich.
Ich h�nge mal einen Ausschnitt (!) der hier dazu bereits dokumentierten
�nderungen dran, das gibt vielleicht einen kleinen Eindruck.
Mir graut schon davor, daran wieder ankn�pfen zu m�ssen...
> Vielleicht stellen wir diesen snapshot-Eintrag insofern etwas
> unter Vorbehalt, indem man einen entsprechenden Hinweis eintr�gt.
Der Fix als solcher ist OK (es wurde halt nur f�r Fido etwas
nachtr�glich implementiert, was f�r die anderen Netztypen ohnehin
bereits implementiert war).
Man m��te wohl sagen, da� auch bei Fido jetzt "X-XP-BOX" erzeugt wird,
u.a. (!) mit der Folge, da� bei N/W/R aus Unversandt-Brett eine vorher
mit "o" im Sendefenster erzwungene Serverbox jetzt beachtet und nicht
mehr zur�ckgesetzt wird. Die �brigen konkreten Folgen dokumentiert man
halt nicht, solange man sie nicht untersucht und zusammengetragen hat.
Getestet haben wir seinerzeit halt prim�r mit RFC und ZConnect.
MichaelMY:
- Umfassende �nderungen und Korrekturen im Zusammenhang mit �ffentlichen
Nachrichten (AMs), die Diskussion-In:-Header (RFC: Followup-To)
enthalten:
----------------------------------------------------------------------
1. Fix: Beim Beantworten mit "B" oder <Ctrl-B> werden jetzt immer die
Schablonen (Kopf, Quote, Signatur) des Zielbretts verwendet.
Existiert das Zielbrett nicht, werden die Schablonen des Bretts
verwendet, in dem die zu beantwortende Nachricht liegt. Sind in der
jeweiligen Brettgruppe keine Schablonen eingetragen, wird jetzt wie
seit jeher in der Hilfe beschrieben die Standard-Quoteschablone
QBRETT.XPS verwendet, die Kopf- und Signaturschablone entfallen.
Bisher wurden immer die Schablonen des Quellbretts verwendet, und
im Falle der Quote-Schablone die (falsche) Schablone QUOTETO.XPS,
die eigentlich nur f�r Weiterleitungen gedacht ist. Relevant ist
diese �nderung auch f�r das Beantworten von Nachrichten aus einem
"MyMail"-Brett heraus.
2. Fix: Eine Antwort auf eine �ffentliche Nachricht konnte unter
zuf�lligen Umst�nden zu der Fehlermeldung "Unbekannte Serverbox:
<Box> - Bitte �berpr�fen!" f�hren, wenn Zielbrett und Serverbox
nicht (oder nicht mehr) existierten (Abfrage auf 'dbfound' fehlte).
Eine Antwort war dann nicht mehr m�glich. :-(
3. Fix: Bei einer Antwort in ein nicht existierendes Diskussion:-In-
Brett wird jetzt nicht mehr die Stammbox als Serverbox benutzt,
sondern die Box des Bretts, in dem die zu beantwortende Nachricht
liegt. Bisher konnte es z.B. vorkommen, da� die Nachricht an eine
Fido-Box gesandt wurde, obwohl es sich um eine Antwort auf ein RFC-
Posting handelte.
4. Fix: Bei einer Antwort auf eine Nachricht mit mehreren Diskussion-
In:-Headern, von denen keines der Bretter bereits existierte, wurde
die Nachricht gesplittet und es wurden �berfl�ssig viele Bretter
angelegt. Jetzt wird die Nachricht als Crossposting
zusammengehalten und nur das erste Brett angelegt.
5. Fix: Bei demselben Szenario f�hrte der Aufruf des Kopien-Dialogs
mit "k" und das anschlie�ende Verlassen mit <Esc> dazu, da� das
Feld "Server" im Sendefenster leer war. Das erste Empf�ngerbrett
wurde dann ohne Serverbox angelegt, die Nachricht an dieses Brett
von den �brigen gesplittet und nur intern versandt. :-(
6. Fix: Der Versuch eines Serverbox-Wechsels mit "o" im Sendefenster
f�hrte zu keiner Reaktion (falls eines der Empf�ngerbretter bereits
existierte) bzw. zu der Fehlermeldung "�nderung der Serverbox nicht
m�glich - inkompatible Netztypen" (falls noch keines der Bretter
existierte). Die Serverbox kann jetzt wie auch bei allen anderen
Nachrichten ge�ndert und wieder zur�ckgesetzt werden; die sog.
"Phantomserver" vor den Namen nicht existierender Bretter im
Kopien-Dialog werden dabei jetzt automatisch angepa�t.
7. Beim automatischen Anlegen eines nicht existierenden AM-Bretts
wurde bisher die Brettgruppe verwendet, die das Quellbrett bzw. ein
gleichnamiges und bereits gel�schtes, in der Datenbank aber noch
vorhandenes Brett hatte. Jetzt wird zus�tzlich darauf gepr�ft, ob
die Brettgruppe gr��er "3" ist (und wenn nicht, das neue Brett mit
Brettgruppe "3" angelegt), damit beim Beantworten aus MyMail-
Brettern mit Brettgruppe "1" oder "2" nicht u.U. interne oder
lokale AM-Bretter angelegt werden.
XP4.PAS, XP6.PAS
MY:
- Fix: Sortierroutine f�r Kopienempf�nger-Liste komplett neu geschrie-
ben. Es wird jetzt au�er der Serverbox auch der PM/AM-Status des
Hauptempf�ngers ber�cksichtigt und die komplette Liste nach diesen
beiden Kriterien zun�chst in "Bl�cke" gegliedert. Innerhalb jedes
Blocks findet dann eine Sortierung nach Codierung (nur PMs) und
Alphabet statt, wobei nicht existierende AM-Bretter mit "Phantom-
servern" - k�nnen z.B. bei Nachrichten mit Diskussion-In:-Headern und
Verteilern entstehen - hinter existierende Bretter sortiert werden.
Damit ist jetzt endg�ltig gew�hrleistet, da� unter allen denkbaren
Umst�nden alle Nachrichten zusammengehalten und als eine Nachricht
(Cc: bzw. Crossposting) versandt werden, bei denen das netztechnisch
m�glich und zul�ssig ist (ZC/RFC). Bisher konnten diverse Szenarien
(z.B. das Hinzuf�gen weiterer Kopienempf�nger oder das Mischen von
PM- und AM-Empf�ngern) immer noch dazu f�hren, da� die Nachrichten
unn�tigerweise gesplittet (und damit mitunter auch unerw�nschte
Bretter angelegt) wurden.
Hinweis: Bei einer Antwort auf ein ZC/RFC-Posting mit einem oder
-------- mehreren noch nicht in XP angelegten Diskussion-In:-Brettern
und dem nachtr�glichen Hinzuf�gen einer Kopie an ein bereits
angelegtes Brett mit derselben Serverbox wird die Nachricht
zwar nicht mehr gesplittet, das erste nicht existierende
Diskussion-In:-Brett aber trotzdem angelegt (obwohl dies
aufgrund des nachtr�glich hinzugef�gten Bretts eigentlich
nicht mehr n�tig w�re). Das ist Absicht, weil das als Kopie
hinzugef�gte und bereits angelegte Brett nicht Bestandteil
der urspr�nglichen Empf�ngerliste war und man i.d.R. den
weiteren Verlauf der Diskussion im ersten Diskussion-In:-
Brett weiterverfolgen m�chte (bestellt werden mu� dieses
Brett dazu nat�rlich dennoch).
XP6.PAS
MY:
- Neues read_verteiler beschreiben
XPCC.PAS
MY:
- Umfassende �nderungen und Korrekturen im Zusammenhang mit dem
Nachrichtenversand an Verteiler:
----------------------------------------------------------------------
1. Fix: Der Versand �ber eine gemeinsame Serverbox an alle Empf�nger
eines Verteilers (= Server im Verteiler eingetragen) wird nur noch
dann durchgef�hrt, wenn alle Empf�nger demselben (bzw. im Falle
einer RFC- oder ZConnect-Box einem adre�kompatiblen) Netztyp ange-
h�ren wie die im Verteiler eingetragene Serverbox. Bisher konnte es
z.B. passieren, da� Nachrichten an Fido-Empf�nger �ber eine RFC-
Serverbox versandt wurden (bzw. wegen fehlerhafter Adressierung
letztendlich eben nicht versandt wurden). Ist der Versand �ber eine
gemeinsame Serverbox nicht m�glich, verh�lt sich XP jetzt so, als
w�re im Verteiler gar keine Serverbox eingetragen gewesen (die
Nachricht wird �ber die Serverboxen versandt, die den jeweiligen
Empf�ngern in den Bretteinstellungen zugeordnet sind). Im Zusammen-
hang mit der neuen Routine zum Sortieren von Kopienempf�ngern
(s.o.) k�nnen damit jetzt in Verteilern AM- und PM-Empf�nger der
unterschiedlichsten Netztypen gefahrlos und in beliebiger Reihen-
folge miteinander gemischt werden - XP wird immer g�ltige und mit
zueinander kompatiblen Daten (Absender, Empf�nger, Serverbox)
versehene Nachrichten erzeugen und diese, soweit netztechnisch
m�glich und zul�ssig, nicht unn�tig splitten, sondern als Mail mit
Cc:-Empf�ngern bzw. als Posting mit Crossposting-Empf�ngern
versenden.
2. Fix: Bei einer Nachricht an einen Verteiler, der User unterschied-
licher Serverboxen enthielt und bei dem aufgrund der im Verteiler
eingetragenen Box eine gemeinsame Serverbox erzwungen wurde, f�hrte
der Versuch, diese erzwungene Serverbox mit "o" und <Esc> zur�ckzu-
setzen, zu einem leeren Feld "Server" im Sendefenster. Derselbe
Effekt trat auf, wenn man mit "k" den Kopien-Dialog aufrief und
einen weiteren Kopienempf�nger hinzuf�gte oder den Dialog mit <Esc>
verlie�.
3. Fix: Der Verteiler wird jetzt auf nicht (mehr) in XP vorhandene
User/Bretter gepr�ft, ggf. eine Fehlermeldung ausgegeben sowie der
Dialog zum Editieren des Verteilers aufgerufen, statt eine Nach-
richt an nicht existierende User und/oder Bretter zu erzeugen. Nur
wenn im Verteiler eine ZConnect- oder RFC-Serverbox eingetragen ist
und es sich bei den nicht vorhandenen Eintr�gen ausschlie�lich um
AM-Bretter handelt, dann wird stattdessen - unter Verwendung dieser
Box als "Phantomserver" - die Nachricht als Crossposting versandt.
4. Die im Verteiler enthaltenen User/Bretter werden nach dem Anlegen
bzw. Editieren des Verteilers jetzt nicht mehr automatisch alpha-
betisch sortiert; dadurch ist gew�hrleistet, da� der erste im
Verteiler eingetragene Empf�nger immer auch der Hauptempf�nger der
Nachricht wird (bisher war das vom User nicht zu beeinflussen).
Ausnahme: Wenn der erste eingetragene Empf�nger ein nicht existie-
rendes AM-Brett ist, sp�ter jedoch mindestens noch ein existieren-
des AM-Brett folgt, das zum selben oder zu einem mit dem im Vertei-
ler eingetragenen Server adre�kompatiblen und crosspostingf�higen
Netztyp geh�rt, dann wird das existierende AM-Brett mit dem
"�hnlichsten" Netztyp zum Hauptempf�nger und die Nachricht an das
nicht existierende AM-Brett innerhalb der neuen Sortierroutine f�r
Kopienempf�nger (s.o.) als Crossposting �ber den "Phantomserver"
versandt. Damit wird vermieden, da� das nicht existierende AM-Brett
neu angelegt wird.
5. Im Verteiler k�nnen jetzt auch nicht existierende AM-Bretter
hinzugef�gt werden, wenn dem Verteiler eine Serverbox eines
crosspostingf�higen Netztyps zugewiesen ist.
6. Verteiler-Nachrichten, bei denen der erste Empf�nger im Verteiler
ein AM-Brett ist, werden in der Versandroutine jetzt auch als AMs
statt als PMs behandelt (bisher bekam man z.B. bei den Zusatzfunk-
tionen mit "u" im Sendefenster nicht den richtigen Dialog angeboten
und konnte kein Followup-To: setzen, selbst wenn es sich beim
ersten Empf�nger im Verteiler um eine RFC-Newsgroup handelte).
7. Wenn es sich beim ersten Empf�nger eines Verteilers im Moment des
Absendens um ein nicht in XP vorhandenes AM-Brett handelt, wird
dieses jetzt mit Brettgruppe 3 (bisher: Brettgruppe 1) angelegt.
8. Fix: Wenn der letzte in VERTEIL.DAT befindliche Verteiler nur mit
einem statt mit zwei CRLFs abgeschlossen war, f�hrte ein Editieren
dieses Verteilers in XP dazu, da� der bisherige letzte Eintrag in
diesem Verteiler zu einem zus�tzlichen Eintrag des vorhergehenden
Verteilers wurde.
XP3.PAS, XP4W.INC, XP6.PAS, XPCC.PAS------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
