PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...
- Section 7 - Einbindung DLIMP / DLTIC in die Maintenance:
Nach jedem Allfix Lauf bei denen TICs erzeugt und/oder verarbeitet wurden kann man entweder DLIMP oder DLTIC
per Semaphore Files antriggern. Meine Empfehlung ist hierzu zwei unterschiedliche Semaphoren zu verwenden.
DLIMP benutzt man sinnvollerweise entweder immer dann wenn kein DLTIC aktiviert ist, oder in Fällen
bei denen neue Files nicht durch das DLTIC System erfasst werden, weil die Areas nicht im Ticker definiert
sind.
Ich selbst habe so eine Reihe von Areas. Für den Pointlist Support existieren zusätzliche
Download Verzeichnisse, die nur jeweils die aktuellste Liste enthalten. Diese Verzeichnisse sind meist
Subdirectorys vorhandener TIC Areas. Zumeist
FREQ (für FileREQuest) benannt.
Diese Areas werden durch die Ticker Konfiguration nicht bedient. Beim Hatch neu eingespeister Dateien
bleiben so diese der jeweiligen zusätzlichen Downloads Area verborgen. Hierzu wird DLIMP benötigt
um
alle Downloads Areas mit der Filebase zu synchronisieren.
Eine zusätzliche Möglichkeit bestünde, indem man die Areas auch zusätzlich im
Ticker definiert und als Magic Rule beim Hatch in die allumfassende TIC Area sich die Datei
in die jeweilige
FREQ Area kopieren lässt. Als einziger Downlink für diese
FREQ
Areas wäre dann die DLTIC Downlink AKA einzutragen. Dann liessen sich diese Areas auch mit DLTIC
bedienen. Allerdings erfolgt bei dieser Art der Synchronisation kein Austausch der Files
(TIC replace mode wird zur Zeit noch nicht unterstützt). Ein Replace der Dateien müsste aber
erfolgen, damit der Datenbestand konsistent bleiben soll.
Würde ich aber nun den Replace Mode in DLTIC aktivieren könnte das für andere Areas
ungeahnte Folgen haben (i.e. Areas in denen Files standardmässig mit einer Replace Option verschickt werden).
Ein anderer Ansatz wäre, DLTIC immer nach einer Allfix Verarbeitung laufen zu lassen und einmal täglich
bei der allgemeinen
Daily Maintenance DLIMP anzutriggern. Somit wären sämtliche
Fälle erschlagen.
Man könnte auch bei regulärer Allfix Verarbeitung nur DLTIC triggern. Beim Hatch besonderer
Files könnte zusätzlich DLIMP angetriggert werden, damit die
FREQ Areas aktuell
gehalten werden. Das bleibt jedem Sysop selbst überlassen, welchen Synchronisationsmode
er benutzen möchte und wann er die Verarbeitung antriggert. Das hängt zum einen von
den Filebase Inhalten ab. Zum Anderen ob Ausnahmen in der Filebase und/oder im Ticker definiert wurden.
Hier versuche ich nur die verschiedenen Aspekte der unterschiedlichen Möglichkeiten aufzuzeigen.
ALLFIX FILE ...
trigger DLTIC reguläre TIC Verarbeitung, keine Ausnahmen
Nodelisten Verarbeitung
HATCH .... nodelist
ALLFIX FILE ... reguläre TIC Verarbeitung mit Ausnahmen
copy nodelist.* ..\freq die nicht durch DLTIC abgedeckt sind
trigger DLTIC
trigger DLIMP
Daily Maintenance
.
.
.
trigger DLIMP täglich 1x Filebase Sync
.
Bei der scheinbar doppelten Verarbeitung DLTIC + DLIMP wird der Eintrag im TIC Verzeichnis
nur einmalig durch das TIC transferiert. Im anschliessenden Synchronisationslauf wird
nur das zusätzliche Verzeichnis aktuallisiert da bei der TIC Verarbeitung die
Informationen des TIC Verzeichnisses bereits aktuallisiert wurden. Die Reihenfolge
zuerst DLTIC aufzurufen und erst anschliessend DLIMP ergibt sich aus der Gesamtmenge
der zu verarbeitenden Fileareas. DLTIC erfasst nur die TIC Areas. DLIMP umfasst sowohl TIC Areas
alsauch zusätzliche Areas die nicht im TIC System definiert sind.
Wird also zuerst DLIMP aufgerufen, findet für das TIC eine Verarbeitung zu einem bereits
zuvor aktuallisiertem Eintrag statt. Schaden tut es aber auch nicht.
Daraus ergibt sich aber auch der Umkehrschluss: wenn keine Fileareas ausser den TIC Areas verarbeitet
werden, wird die DLIMP Synchronisation nicht noch zusätzlich benötigt gleichwohl
für das DLTIC System eine DLIMP Konfiguration existieren muss.
