Project: PHP-Nuke - 04. FileBase to Download Import - Analyse Ticker
-
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 4 - Analyse II, Ticker Import
ALLFIX 5.13 structures: grpfile.fix + fareas.fix
fareas.fix ---------- 00000 06 50 44 4E | 41 53 4D 00 | 00 00 00 00 | 00 00 00 00 .PDNASM......... [1] [40] -> 00010 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 00020 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ ->| [1] [12] message -> 00030 00 00 00 00 | 00 00 15 50 | 44 4E 20 2D | 20 38 30 78 .......PDN - 80x ->| [1] [55] comment -> 00040 78 78 20 41 | 73 73 65 6D | 62 6C 65 72 | 00 00 00 00 xx Assembler.... 00050 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 00060 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 01 53 ...............S ->| [1] group^ attrib^ [2] 00070 01 FF 00 00 | 0E 51 3A 5C | 50 44 4E 5C | 50 44 4E 41 .....Q:\PDN\PDNA ->| [1] [1][60] destdir -> keeplate^ 1..10 comment ^ [1] uplink [1]^ len[1]^ 00080 53 4D 5C 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 SM\............. 00090 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 000A0 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 000B0 00 09 00 DE | 03 61 09 00 | 00 FF 02 00 | 00 00 00 00 .....a... ...... 000C0 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 000D0 00 00 00 40 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ...@............ record length = 2535 pos len desc ------- ---- ------------------ 1 [1] len tag 2 [40] tag 42 [1] len message 43 [12] message 55 [1] len comment 56 [55] comment 111 [1] group 112 [2] attrib 114 [1] keeplate 115 [1] convert 116 [1] uplink 117 [1] len destdir 118 [60] destdir do while not eof() line = readblock[2535] ltag = hextodec( substr(1,1) ) tag = substr(2,ltag) lcomment = hextodec( substr(55,1) ) comment = substr(56,lcomment) lpath = hextodec( substr(117,1) ) path = substr(118,lpath) enddo grpfile.fix ----------- 00000 04 50 44 4E | 2A 00 00 00 | 00 00 00 00 | 00 00 00 00 .PDN*........... 00010 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 00020 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 00030 00 00 00 00 | 00 00 1C 50 | 72 6F 67 72 | 61 6D 6D 65 .......Programme 00040 72 73 20 44 | 69 73 74 72 | 69 62 75 74 | 69 6F 6E 20 rs Distribution 00050 4E 65 74 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 Net............. 00060 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 01 13 ................ grp attr 00070 01 FF 00 00 | 07 51 3A 5C | 50 44 4E 5C | 00 00 00 00 .....Q:\PDN\.... [...] 009E0 00 00 00 00 | 00 00 00 03 | 50 44 4E 00 | 00 00 00 00 ........PDN..... 2528+ 1 2 3 4 5 6 7 8 2536 009F0 00 00 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 00 ................ 00A00 00 04 53 44 | 53 2A 00 00 | 00 00 00 00 | 00 00 00 00 ..SDS*.......... 2561 ->| record length = 2561 pos len desc ------- ---- ------------------ 1 [1] len mask 2 [40] mask 42 [1] len message 43 [12] message 55 [1] len comment 56 [55] comment description 111 [1] group group # 112 [2] attrib 114 [1] keeplate 115 [1] convert 116 [1] uplink 117 [1] len destdir 118 [60] destdir path ... 2536 [1] len group tag 2537 [25] group tag do while not eof() line = readblock[2561] lmask = asc( substr(1,1) ) mask = substr(2,ltag) lcomment = asc( substr(55,1) ) comment = substr(56,lcomment) lpath = asc( substr(117,1) ) path = substr(118,lpath) lgtag = asc( substr(2536,1) ) gtag = substr(2537,lpath) enddo
Auszug aus der Test Ausgabe: Ausgabe Groups 1..49------------------------------------------------------------ AreaTag : PDNASM Comment : PDN - 80xxx Assembler AreaPath : Q:\PDN\PDNASM\ GroupTag : PDN GroupMask: PDN* GroupPath: Q:\PDN\ ------------------------------------------------------------ AreaTag : PDNBASIC Comment : PDN - Basic (DOS) AreaPath : Q:\PDN\PDNBASIC\ GroupTag : PDN GroupMask: PDN* GroupPath: Q:\PDN\ ------------------------------------------------------------ [...] ------------------------------------------------------------ AreaTag : GNF.TOBIT Comment : Tobit AreaPath : Q:\GNF\TOBIT\ GroupTag : GNF GroupMask: GFN.* GroupPath: Q:\GNF\ ------------------------------------------------------------
see also DEVELOP.ZIP [00] Allfix 5.13 SDK (structures info)
[3.8.05]
Das nächste Problem für den TIC Import ergibt sich aus dem Inhalt.
Während man bei der Filebase Synchronisation von einem 1:1 Verhältniss der Verzeichnisse ausgehen kann, ist dies beim Ticker nicht zwangsläufig mehr gegeben. Hier besteht die offene Möglichkeit dass mehrere TIC Areas auf ein physikalisches Verzeichnis zeigen. Ganz konkret ist das bei mir mit der SERVICE Area so. Es ist ein Verzeichnis in der FTN-Filebase. Es ist ein Verzeichnis in der DOWNLOADS Section, aber es sind mehrere TIC Areas, die auf dieses Verzeichnis zeigen: ELIST244, NODEDIFF, NODELIST, POINTS24, R24-LIST, NET244, POINT244, 24000, POINT4D. Das sind zusammen 9 FileEchoes, davon sind 7 FileEchoes aktiv.
Da die DLIMP Filearea Synchronisationstabelle eine 1:1 Liste der Verzeichnisse darstellt, und jetzt eine 1:n Relation zu Tic Areas auftritt, muss entweder die Struktur für die DLIMP Tabelle erweitert, oder eine eigene neue Tabelle erstellt werden. Es wird wohl auf letzteres hinauslaufen um die 1:n Relation aufzulösen.
Da der Transport nur in eine Richtung vorgesehen ist (n->1) ist mit Hilfe einer zusätzlichen Tabelle und einem Verzeichnis Schlüssel der dann in die DLIMP Tabelle mit aufgenommen wird wohl am ehesten gedient.
Da es bereits einen eindeutigen Schlüssel für die Downloads Areas gibt, kann auch dieser Schlüssel für die TIC Areas herangezogen werden.
DLIMP TIC TID MAX-AREA PATH DL-AREA 1:n KEY TIC-AREA (PATH) 23 SERVIC Q:\SERVICE SERVICE 23 NODEDIFF Q:\SERVICE 23 POINTS24 Q:\SERVICE 23 R24-LIST Q:\SERVICE 23 24000 Q:\SERVICE 23 POINT4D Q:\SERVICE
Mit dieser vereinfachten TIC Tabellen Struktur lässt sich jetzt aber keine Import Routine für den Aufbau der DLIMP Tabelle ohne vorherigen FileBase Import konstruieren. Sprich: die DLIMP Tabelle muss bereits vorher vorhanden sein (siehe auch Projekt Steps 1 + 2).
Auf der anderen Seite liefert aber gerade die Ticker Konfiguration die Gruppen Infos, die bei der FileBase Synchronisations Routine in Step 1 (import routing definitions) mühsam manuell vordefiniert werden müssen.
Kleines Gedankenspiel: Ticker Gruppe GFD mit Basepath Q:\GFD wäre in der Step 1 Tabelle (tempimp) mit der Gruppe GFD unterzubringen. Allerdings ergibt sich jetzt das Problem, welchen Parentname nehme ich nun für diese Gruppe?
Bei der TEMP Routing Definition war das vorgegeben und lautete auf FILEBASE. Diese Information fehlt mir jetzt aber. Diese Information steht mir zwar aus dem Step 1 noch zur Verfügung, aber ohne die Ausführung von Step 1 gäbe es diese Information überhaupt nicht. Also ist auch für den Ticker Konfigurations Import (hier Gruppennamen Import) Step 1 eine Grundvorraussetzung um einen Anhaltspunkt zu erlangen, wie die TIC Areas in der Downloads Section organisiert werden sollen (siehe 'ROUTING' Config File for Areas to Categories relations).
Wenn Tabelle *_downloads_tempimp existiert, wurde Step 1 ausgeführt, andernfalls Abbruch des Konfigurations Imports.
[5.8.05]
Aufgrund eines anderen Projekts ruht zur Zeit die Weiterentwicklung ...
[29.1.06]
DLIMP v1.01
* Fixed Updated Files in Filebase. Beim Filebase2Download Import wird nun bei allen aktuallisierten Dateien, auch wenn sich die Description nicht verändert hat (statische Files, i.e. NODELIST.ZIP) Filesize und das Einspeisungsdatum aktuallisiert sofern sich FILES.BBS verändert hat.
Area NODELIST-FRQ dagegen wird weiterhin nicht aktuallisiert, da sich FILES.BBS nie ändert. Dagegen hilft es bei der Area SERVICE, die ständig aktuallisiert wird.
+ Added Directory Filesize Check. Um Änderungen innerhalb eines Directorys identifizieren zu können, auch wenn sich eine Filedescription nicht geändert hat, kann aber eine geänderte Filesize Aufschluss darüber geben, dass sich im Verzeichnis etwas geändert hat. Günstiger wäre zwar eine Gesamt-CRC über alle Files einer Area, für den Anfang hilft aber auch schon die Filesize Summe. Status: fixed.
| © 2003-2024 by Ulrich Schroeter | 01107 | |