AMBROSIA60 Portal  

 
| | News | Sitemap | Startseite | Kontakt | Impressum |

Project: PHP-Nuke - 07. FileBase to Download Import - IMP/TIC Maintenance

AMBROSIA60-Portal  FileBase to Download Import Project



PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...




Übersicht:
Start....Übersicht
Section 1....Analyse I, Filebase Synchronisation
Section 2....Umsetzung der Filebase Synchronisationsprozedur
Section 3....FileBase Import, Allgemeine Beschreibung
Section 4....Analyse II, Ticker Import
Section 5....Umsetzung des TIC Imports
Section 6....TIC Import, Allgemeine Beschreibung
Section 7....Einbindung DLIMP / DLTIC in die Maintenance
Section 8....Hinweis zur FileBase Security
Section 9....Übersicht und Status Gesamtprojekt
Section 10....References
Section 11....Download
Section 12....Weiterentwicklungen, Fixes







  • 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.





AMBROSIA60 News RSS 2.0 feed [Valid RSS]
Future4Fido
[ Join Now | Ring Hub | Random | << Prev | Next >> ]

©WebRing Inc.
FidoNet World Wide WebRing
<< Prev | Ring Hub | Join | Rate| Next >>
www.CAcert.org
SSL Powered
© 2003-2017 by Ulrich Schroeter Besucherzaehler