hallo leute,

ich habe mich heute mal ein klein wenig bei sourceforge.net umgeschaut; danke @pq

zur Konfig:
da gefaellt mir pq's Idee recht gut (ich hoffe, ich habe sie richtig verstanden), die ganze konfig in einen Hash (oder mir waere Hashref lieber) zu laden und den dann ueber den Exporter als $Config->{PageName} oder so verfuegbar zu machen. Ist auch viel kuerzer als $PBoard::Config::PageName.

Ich ueberlege gerade, ob es Sinn macht, die Config aufzuteilen. %TagsFirstReplace, %TagsBlocked, %TagsFastReplace und TagsLastReplace enthaelt Perl-Code, hat aber mit dem Rest der Config nicht allzu viel zu tun, und koennte gut in einem Perl-Modul stehen.

Als Config-Modul gefaellt mir eigentlich YAML recht gut, vielleicht, weil ich schon oefter damit gearbeitet habe. Ich habe aber geruechteweise gehoert, dass es bei YAML Probleme mit dem Schreiben geben soll (stimmt das/hat sich das schon erledigt/war das nur bei Perl-Datenstrukturen?). Ich schaetze mal, dass irgendwann mal auch ein Admin-Interface nett waere, das diese Konfig veraendern kann, und da sollten wir ein Modul waehlen, mit dem man auch gut schreiben kann. Ob wir mit Config::Inifiles auskommen, weiss ich nicht, dazu habe ich zu wenig mit diesem Modul gemacht. auf jedem fall sollten konstrukte wie

- also das verwenden von Variablen darin - moeglich sein.

Wenn man die Config schon beim server-startup laedt, muesste bei mod_perl eigentlich keine Performance verloren gehen; bei CGI kostet es halt ein bisschen was, ein Modul anstelle des Perl-Moduls zu verwenden.

.perltidyrc wuerde ich in jedem Verzeichnis ablegen, in dem Perl-Scripte oder Module liegen; perltidy versucht naemlich zuerst die aus dem aktuellen verzeichnis zu laden; das duerfte die sache am einfachsten machen.

[s]zu CPAN: ich verstehe den sinn nicht ganz, wieso man das board wie ein Perl-Modul ueber die CPAN-Shell installieren koennen soll. Ich bevorzuge den "klassischen" Weg als tar.gz und die dateien ueber ein install-script an die richtigen stellen kopieren; dann kann man die leute auch dazu zwingen, pfade anzugeben, und die Module verschwinden nicht einfach in irgendeinem site/perl.../ - verzeichnis, sondern das Board ist auch einfach wieder deinstallierbar, indem man ein oder zwei verzeichnisse loescht (nicht jeder kennt perl Makefile.PL PREFIX=...). Allenfalls ein dummy-modul, ueber das die ganzen benoetigten Abhaengigkeiten von CPAN automatisch installiert werden koennen, halte ich fuer sinnvoll. Bitte erklaert mir den Sinn.[/s]

[edit|strat] habe den Sinn jetzt kapiert, und finde es gut[/edit]

Zur Verzeichnisstruktur: gefaellt mir sehr gut. Zusaetzlich schlage ich noch folgendes vor:
data/ht_cache
data/backup (dann koennen dort in Zukunft mal Backups der DB abgelegt werden, z.B. ferngesteuertes mysqldump)

conf/apache.conf.template: man kann ja in der Apache-Config mit Include /my/file.conf weitere Dateien einbinden; waere es nicht am einfachsten, die apache-config auch zum PBoard abzulegen und dem Installierenden nur zu sagen, er soll die in die httpd.conf reinlinken?




Ich schlage auch vor, die ganze CPAN-Geschichte zu verschieben, bis das Board mal stabil laeuft. Da ist naemlich schon noch das eine oder andere wichtige.\n\n

<!--EDIT|Strat|1154121070-->

nochmal zur konfig: (zur idee von betterworld): wuerde es nicht sinn machen, die serverspezifische konfig (zugangsdaten, pfade, ...) von der nicht-server-spezifischen zu trennen? dann koennte man einfacher zeug zwischen verschiedenen servern austauschen (wuerde gerade fuer mich super sein, weil ich unter winXP entwickle und unter linux teste).

[quote=Strat,20.07.2006, 23:35]Als Config-Modul gefaellt mir eigentlich YAML recht gut, vielleicht, weil ich schon oefter damit gearbeitet habe. Ich habe aber geruechteweise gehoert, dass es bei YAML Probleme mit dem Schreiben geben soll (stimmt das/hat sich das schon erledigt/war das nur bei Perl-Datenstrukturen?). Ich schaetze mal, dass irgendwann mal auch ein Admin-Interface nett waere, das diese Konfig veraendern kann, und da sollten wir ein Modul waehlen, mit dem man auch gut schreiben kann. Ob wir mit Config::Inifiles auskommen, weiss ich nicht, dazu habe ich zu wenig mit diesem Modul gemacht.
[/quote]
OK, dann ist wohl die Mehrheit dafuer, YAML zu benutzen. Es sollte nicht viel Arbeit sein, den jetzigen Code, der Config::IniFiles benutzt, entsprechend umzuschreiben.

Quote

conf/apache.conf.template: man kann ja in der Apache-Config mit Include /my/file.conf weitere Dateien einbinden; waere es nicht am einfachsten, die apache-config auch zum PBoard abzulegen und dem Installierenden nur zu sagen, er soll die in die httpd.conf reinlinken?

Genauso habe ich es gemacht. Einfach die apache.conf mit installer.pl generiert und dann in httpd.conf gesagt:

Was willst Du daran noch aendern?

apropos: will wer von euch den release-manager machen? ich bin zwar bereit, es weiterhin zu machen, bin aber leider wegen meiner arbeit und fahrtzeit oft unzuverlaessig, und ich code lieber ;-)

[quote=betterworld,20.07.2006, 23:46]Genauso habe ich es gemacht. Einfach die apache.conf mit installer.pl generiert und dann in httpd.conf gesagt:

Was willst Du daran noch aendern?[/quote]
bevor ich es mir angeschaut habe, nichts. Und vermutlich auch, nachdem ich es mir angeschaut habe, nichts :-)

btw: upload.pl und download.pl funktionieren wahrscheinlich noch nicht; die muss ich auch mal umstellen

dafuer brauchen wir noch ein verzeichnis namens attachments/ oder aehnlich ...\n\n

<!--EDIT|Strat|1153432881-->

die admin-tools müssen auch noch eingecheckt werden...

templates sind IMHO in conf/templates oder templates/ besser aufgehoben als in html/templates\n\n

<!--EDIT|Strat|1153433370-->

zu den admin-tools: ich habe die mal quick'n'dirty gecoded; ich denke, da wuerde eine admin-gui wie beim ikonboard mehr sinn machen (vielleicht besser als cgi, weil's da nicht auf geschwindigkeit ankommt); wenn man funktionalitaet fuer cronjobs braucht, kann man die ja auch mit einem kleinen Perl-Wrapper in einen cronjob reinhaengen

appropos yaml, schaut euch mal nach yaml::Syck um und wenn es einmal stabil ist wäre yaml::tiny auch was da yaml sehr viel speicher frisst mehr als es für euren gebrauch akzeptabel ist da ihr eh nur 3% seiner fähigkeiten nutzen werdet.