Perlmodul als Configfile automatisch schreiben

[Alexander (HH)]

Moin Moin!

Irgendwann wird jemand die Konfiguration manuell ändern müssen, da ist dann ein bekanntes, einfaches Format meistens weniger anfällig als ein Modul, das als Perl-Code geparst wird.

Nein, für die Userkonfiguration soll es eine GUI geben.

Was eine INI- oder JSON-Datei trotzdem nicht ausschließt.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

Warum so umständlich?

Starte das Script, suche nach Updates, installiere Updates, aktualisiere die Konfiguration, starte die eigentlich angeforderte Aufgabe. Das geht in einem Programmlauf.

...Elend langsam. Das machst du nicht bei einer komplexeren Anwendung für jeden HTTP Request.

Nö, nur beim Start der Anwendung und ggf. nach einer einstellbaren Zeit nochmal. Oder willst Du für jeden HTTP-Request den Perl-Compiler/Interpreter nochmal anwerfen?

Updates gibt es verschiedener Art:
Softwareupdates (selten)
Userdataupdates (wohl häufig)
Aber in der Regel kann aus einer konstanten Konfiguration bedient werden, die eben möglichst geradlinig Perl bereitstehen soll.

Bei jedem Scriptrun ein nicht optimiertes Format, egal welcher Art einzulesen, ist eindeutig ein NoGo.

Aber die Startup-Kosten von Perl stören Dich nicht?

Perl-Code muß auch nochmal durch den Perl-Parser (der definitiv alles andere als trivial ist). "Optimiert" ist das auch nicht.

Überlege mal, ob ein schnell zu ladendes binäres Format Deine Anforderungen erfüllt. Storable könnte eine Idee sein.

Vergleiche das aber mal mit dem Aufwand, den JSON::XS für die gleiche Datenmenge treibt. Ich schätze, dass der Aufwand in beiden Fällen ähnlich niedrig ist, verglichen mit dem Rest der Applikation, und deutlich niedriger als require file bzw. use module. Und JSON hat den Vorteil, dass man im Notfall Hand anlegen kann.

Wie gesagt. alles woran man nicht rumfuchteln darf ist derzeit
<quote>
1;

</quote>

Was für eine unnötige Einschränkung, die require Dir da aufbrummt. do $filename hat diese Einschränkung nicht.

Dieses mit Sinn zu füllen soll nicht bei jedem Run, sondern nach Updates, Inhaltsaktualisierungen durch den Admin geschehen, via Push-Button

Inhalte gehören in die DB, nicht in die Konfiguration.

Warum das wichtige in Datenbanken verstecken,

Weil Dir das Ärger mit Locking, zerschossenen Dateien und World-Writeable-Verzeichnissen abnimmt.

um es dann drei/viermal umzuformen?

Paßt Dein DB-Schema nicht zur Anwendung, dass Du die Daten so oft umformen mußt?

Ich verfolge eine Absicht wenn ich die notwendige Konfiguration in ein .pm stecken will.

Ich bezweifle nur, dass das der beste Weg ist. Offensichtlich möchtest Du im Web-Kontext arbeiten. Du hast eine Applikation, deren Konfigurationsdatei und deren Programmverzeichnis für den Webserver schreibbar sein muß. Das ist definitiv keine gute Idee.

Alexander