nicht angemeldet
Guten Tag Philip ;-)
Nochmals einzele Antworten zusammengefasst und nachgefragt:
... Aber es gibt die Möglichkeit, die XML-Config _einmal_ zu parsen und den ParseTree von XML::DOM im Speicher zu halten. Dann kannst du über das Socket durch diesen ParseTree "browsen", aber es werden gar keine XML-Files mehr geparsed. Übrigens: XML::DOM ist auch ziemlich lahm. XML::SAX wäre da viel, viel schneller, aber das "browsing" wird etwas mühsamer, wie ich denke. Aber wie gesagt, die Datei muss nur einmal geparsed werden (OK, das Traversieren/Durchlaufen des ParseTree ist bei XML::DOM auch etwas unperformant).
[...]
So was in der Art könnte ich mir vorstellen. Für die oben genannte XML-Schnittstelle habe ich mir schon ein XPath-ähnliches Interface geschrieben, werde nun aber auf das Modul XPath wechseln. Damit sollte sich so was grundsätzlich lösen lassen, aber wie gesagt, dazu muss jedes einzelne Objekt bei jedem Skriptaufruf nochmals durch den XML-Parser ... :-(
Mit einigen Anpassungen nicht. Der ParseTree liegt ja im Speicher des Daten-Scripts. Du musst dein XPath-Modul nur so abändern, dass es durch das Socket kommuniziert und ein anderes XPath-Modul im Daten-Script aufruft, der den Node zurückliefert (ohne das XML neu zu parsen => das XPath Modul muss auf den Memory-ParseTree von XML::DOM zugreifen).
Aktuell setze ich das Modul XML::Parser mit Style=Object ein, das ein etwas merkwürdiger Objektbaum zurückliefert.
Darüber habe ich eine eigene XML-Klasse gestrickt, welche eine Zugriff auf die XML-Elemenet mit Methoden wie getNodeByID(), getNodesByElement(), etc. zurückliefert.
Zufällig bin ich nun aber über das Modul XML::XPath gestolpert, das noch viel umfangreicher Funktionalität bietet und vor allem schon fertig ist. Dieses Modul verwendet aber einen eigenen Parser (XML::XPath::Parser). Wie schnell dieser ist, weiss ich aktuell noch nicht, aber er basiert ebenso wie XML::Parser auf dem Expat-Parser.
Wo bekomme ich eigentlich das Modul XML::SAX her? Auf CPAN habe ich es nicht gefunden.
Zurück zum Problem.
Die XML-Daten werden durch den übergelagerten Daten-Server geparst der resultierende Tree im Speicher gehalten.
Nun kommuniziere ich von den Darstellungsskripts mit XPath-Anweisungen (sind ja relativ kurze einfache Befehle, bzw. Strings)
zum Datenserver.
Falls ich alle Anfragen zum Datenserver so formuliere, dass er mir nur Attributwerte oder Elementinhalte (Text) zurückliefern muss, dann kann ich mir die Seriealisierung tatsächlich sparen. Sollte ich aber Auflistungen von Objekten (als Hashes oder Arrays) benötigen, so komme ich um die Serialisierung nicht herum und dies kostet wieder Performance.
Darüber werde ich noch nachdenken müssen.
Danke aber erst mal für die konzeptionelle Idee.
[...]
Nun, fork läuft auf allen Unix-Derivaten. Bekanntlich gehört Win leider nicht dazu... *sorry*
Mal sehen, ob ich hierfür eine eigene Win32-Variante entwickle oder die Win32-Lösung nur bei kleinen Installationen in Frage kommt, bei denen ein Datenserver ausreicht.
Es ist übrigens nicht schwer, ganze Objekte in der Datenbank abzubilden. Dazu brauchst du nur einen Mapper, der das Objekt in eine relationale Form bringt... Oder vielleicht hast du ja gar eine OODBMS ;)
Hab ich auch schon gemacht und funktioniert prima.
Eine RDBMS setze ich auch als persistener Datenspeicher ein. XML ist nur die Import-/Export-Schnittstelle zu Fremdsystemen.
Im ersten Schritt werde ich alle Objekte bei jedem Skriptaufruf aus der Datenbank laden.
Die Lösung mit dem Datenserver und der Socketkommunikation hebe ich mir für Installationen mit höheren Anforderungen auf.
Trotzdem vielen Dank für die Anregungen.
Grüsse
Eisbär