Forumssoftware von Sourceforge laden
Bio
- zu diesem forum
Sup!
Dieses Forum ist bekannterweise mit Abstand am coolsten und wesentlich besser als die Spacko-Software vBulletin, die nur von hirnlosen Losern benutzt wird.
Darum wollte ich auch selbst so ein Forum installieren... allerdings hat mich Sourceforge so ein wenig verwirrt... im CVS sieht es so aus, als waeren alle Dateien schon 6 Monate alt, aber die "Aktivität" von immerhin ein paar Prozent legt nahe, daß noch letzte Woche was dran gebastelt worden ist. Wie also bekomme ich die neueste und beste und stabilste Version des Forums... und warum kann ich es nicht bei CPAN runterladen, so daß alle nötigen Module automatisch installiert werden und man nur noch gaaaanz wenig konfigurieren muß, um so ein Forum zu haben? Als Apprentice of Perl weiß ich natürlich ganz genau, daß die Perl-Wizzards, die das Forum erschaffen haben, nur ca. 3 Minuten brauchen, um ein CPAN-Installations-Paket mit den Zehen zu schreiben ;-)
Ne, mal ernsthaft, wie mache ich das am besten? Einfach die 0.98 runterladen und selbst probieren?
Gruesse,
Bio
Dieses Forum ist bekannterweise mit Abstand am coolsten und wesentlich besser als die Spacko-Software vBulletin, die nur von hirnlosen Losern benutzt wird.
Was hast du denn gegen das vBulletin, haste das etwa nicht mitbekommen, dass wir alle dafür plädieren, auf diese Engine umzusteigen *g*
MfG, ABS
Moin
Dieses Forum ist bekannterweise mit Abstand am coolsten und wesentlich besser als die Spacko-Software vBulletin, die nur von hirnlosen Losern benutzt wird.
Was hast du denn gegen das vBulletin, haste das etwa nicht mitbekommen, dass wir alle dafür plädieren, auf diese Engine umzusteigen *g*
es kann jawohl nicht sein. deine antwort hat Bio nicht im geringsten geholfen, und wenn du ihr nicht produktiv helfen kannst (wovon ich ausgehee), dann lass diese kommentare, sie bringen nix.
wenn du das Forum nicht magst, musste ja nicht hier posten, vor allen Dingen so einen unsinn.
MfG, ABS
Fabian
Hallo,
es kann jawohl nicht sein. deine antwort hat Bio nicht im
geringsten geholfen, und wenn du ihr nicht produktiv helfen
kannst (wovon ich ausgehee), dann lass diese kommentare, sie
bringen nix.
wenn du das Forum nicht magst, musste ja nicht hier posten,
vor allen Dingen so einen unsinn.
Du weisst, was Humor und Ironie sind?
Gruesse,
CK
Nur mal so als kleiner Hinweis:
Würd dem Bio vielleicht ja doch ma helfen, wenn ihr jetzt grad keine Grundsatzdiskussion ueber Foren sondern eher mal n wirklichen Tipp ihm geben wuerdet. *moralapostel spiel*
Naja...würd gern helfe, hab aba keine Ahnung.
MfG, Sting;
Was hast du denn gegen das vBulletin, haste das etwa nicht mitbekommen, dass wir alle dafür plädieren, auf diese Engine umzusteigen *g*
es kann jawohl nicht sein. deine antwort hat Bio nicht im geringsten geholfen, und wenn du ihr nicht produktiv helfen kannst (wovon ich ausgehee), dann lass diese kommentare, sie bringen nix.
wenn du das Forum nicht magst, musste ja nicht hier posten, vor allen Dingen so einen unsinn.
Ehm, weißt du, was das *g* bedeutet? Das steht für Witz, Ironie, solche sachen halt. Und wenn du ein ganz ganz ganz klein bisschen weiter unten im Forum schaust, wirst du merken, dass ich selbst gegen ein vBulletin oder was auch immer bin.
Und übrigens bei aller "Produktivität", die du so hier vertrittst: einwenig Humor _darf_ man ja wohl noch an den Tag legen.
MfG, ABS
Entschuldigung,
ich habe ernsthaft das *g* überlesen, wohl, weil ich diesen Post etwas "angesäuert" gelesen habe (was grundsätzlich schlecht ist, um ordentliche antworten zu geben).
In dem Sinne möchte ich mich bei allen entschuldigen, die sich dadurch angestoßen fühlten.
Sorry.
Fabian
nT = no Text ;-)
MfG, ABS
Sup!
Hmmm... Erst wenn die letzte Ölplattform verschrottet, die letzte Pipeline abgebaut und die letzte Tankstelle geschlossen ist, werdet ihr feststellen, daß Greepeace nachts kein Bier verkauft!
Aber ne, nie, nie, nieeeeeeemals werde ich ein PHP-Board auf meinem Server installieren, wenn ich nicht _ultraviel_ Geld dafür bekomme.
Gruesse,
Bio
Hi!
Hmmm... Erst wenn die letzte Ölplattform verschrottet, die letzte Pipeline abgebaut und die letzte Tankstelle geschlossen ist, werdet ihr feststellen, daß Greepeace nachts kein Bier verkauft!
;-)
Aber ne, nie, nie, nieeeeeeemals werde ich ein PHP-Board auf meinem Server installieren, wenn ich nicht _ultraviel_ Geld dafür bekomme.
Wieso nicht, Du mußt ja nicht diese Klicki-Bunti-Dinger installieren, gibt auch andere, und selbst ist es auch recht einfach, wie der eine featured Artikel zeigt!
Grüße
Andreas
Hallo!
Das Forum wird gerade neu Programmiert, wohl gemerkt als C Anwendung!!!
http://forum.de.selfhtml.org/archiv/2002/6/14899/#m83043
Warte noch ein bisschen, dann kannst Du alle Deinen so geliebten klicki-bunti Features nutzen ;-)
Grüße
Andreas
hi!
Ne, mal ernsthaft, wie mache ich das am besten? Einfach die 0.98
runterladen und selbst probieren?
Die letzte und aktuellste Version liegt im CVS. Die downloadbare
Version 0.98 ist stark veraltet (viele Bugs, fehlende Funktionen).
Alle Module, die zusätzlich zu den Standard-Modulen benötigt werden,
sind CGI und XML::DOM.
Die Aktivität kommt nicht durch Weiterentwicklung zustande, sondern
durch die Anzahl der Website-Abrufe bzw. der Downloads.
Im übrigen wird die Perl-Version des SELFFORUMs nicht weiterentwickelt.
Sie befindet sich allerdings auf dem selben Stand wie dieses Forum
und ist damit wohl hinreichend für die Verwendung qualifiziert.
bye, Frank!
Hallo!
Im übrigen wird die Perl-Version des SELFFORUMs nicht weiterentwickelt.
Wieso verwendet Ihr für dei neue Version eigentlich C? Ist das nicht sehr viel aufwändiger und ist C soviel schneller als PERL?
Das doofe ist nur, eine C-Verion kann man nicht auf jedem gehosteten Webserver installieren, oder kann man das einfach wie andere Tools installieren?
Grüße
Andreas
hi!
Wieso verwendet Ihr für dei neue Version eigentlich C? Ist das nicht
sehr viel aufwändiger und ist C soviel schneller als PERL?
Es ist viel schneller als Perl, vor allem beim Starten.
Das doofe ist nur, eine C-Verion kann man nicht auf jedem gehosteten
Webserver installieren, oder kann man das einfach wie andere Tools
installieren?
Kann man. Vorkompilierte Versionen kann man einfach ins cgi-bin-
Verzeichnis hochladen und von dort ausführen. Wenn man shell-Zugang
hat, zb. per Telnet oder SSH, kann man auf einem Unix sogar den
C-Source selbst kompilieren.
bye, Frank!
Hi Andreas,
Wieso verwendet Ihr für dei neue Version eigentlich C? Ist das nicht
sehr viel aufwändiger und ist C soviel schneller als PERL?
da Christian hier nicht eingestiegen ist, versuche ich mal, aus meiner
Erinnerung zu plaudern. Ich bin nicht ganz auf dem Stand der Entwick-
lung, glaube aber, die Zielsetzung halbwegs verstanden zu haben.
Das, was das Forum im Moment langsam macht, ist weniger Perl an sich,
sondern mehrere andere Probleme:
1. Es müssen ständig XML-Strukturen geparsed werden, und dafür wird
ein Perl-Modul verwendet, das nicht so irre schnell ist, dafür aber
viel mehr kann, als das Forum mit seinen relativ einfachen XML-
Strukturen braucht.
2. Da beliebig viele Benutzer gleichzeitig auf das Forum zugreifen
und dabei potentiell gleichzeitig posten können, müssen viele der
Zugriffe synchronisiert werden.
3. Zudem führt jedes Posting zur Änderung nicht nur des kompletten
Threads, sondern zudem noch zur Änderung der Hauptdatei - also muß
all dies während eines Posting-Vorgangs gesperrt werden (deshalb
behindern mehrere Posting-Versuche einander).
4. Und all dies auf einem Server, der ohnehin nicht beliebig leistungs-
fähig ist und zudem ab und zu von unfreundlichen Leuten mit Daten-
müll beschossen wird.
Das neue Forum soll diese Probleme lösen:
a) Es soll ein neuer, selbst geschriebener (einfacher, aber schneller)
XML-Parser entstehen, der auf die Bedürfnisse der Forums-Daten-
formate optimiert arbeitet. (Ich glaube, lex und yacc dienen ent-
weder als Grundlage oder doch wenigstens als Ideengeber.)
b) Die gesamte Kommunikationsstruktur soll geändert werden. Bisher
"reden" alle CGI-Skripte direkt mit der Festplatte; künftig sollen
die CGI-Skripte selbst nur noch Clients sein, die Anforderungen
an einen zusätzlichen, permantent laufenden Forums-daemon stellen
(über Interprozeßkommunikation, z. B. ein socket).
Dieser daemon serialisiert dabei alle Anforderungen, und es sind
keinerlei gegenseitigen Sperren mehr notwendig, weil nur noch der
daemon auf die eigentlichen Datenobjekte zugreifen darf.
Außerdem kann der daemon natürlich das gesamte Forum im Haupt-
speicher halten (so viel kosten die paar hundert Dateien ja nicht
an RAM), was erheblich an Festplattenzugriffen einspart; damit
würde nicht nur das Posten, sondern ggf. auch das Lesen schneller
werden bzw. den Server weniger belasten.
Du siehst, daß diese neue Version nicht mal eben in der Änderung von
ein paar hundert Zeilen Code besteht - da werden ganz neue Konzepte
aus dem Boden gestampft.
Und die müssen nicht nur implementiert, sondern vor allem auch gut
getestet werden - bei der Kommunikation zwischen dem daemon und seinen
Clients darf nichts schief gehen, sich nichts aufhängen usw. - wenn
der daemon kaputt gehen sollte, wäre das gesamte Forum lahm gelegt
und müßte manuell neu gestartet werden. Das funktioniert dann eher
wie eine Datenbank, also ganz anders als eine Handvoll CGI-Skripte.
Dafür aber könnte das Ergebnis im Vergleich zum bisherigen Forum
wirklich _rasend_ schnell werden - weil ein großer Teil dessen, was
bisher immer wieder gemacht werden muß, durch eine intelligentere
Architektur überflüssig wird.
Das doofe ist nur, eine C-Verion kann man nicht auf jedem gehoste-
ten Webserver installieren, oder kann man das einfach wie andere
Tools installieren?
Für bestimmte häufig vorkommende Plattformen (Linux etc.) kann man
natürlich Binaries zum Download bereit stellen - beim Apache ist das
ja genauso, den übersetzt auch fast niemand unter Windows selbst.
Viele Grüße
Michael
Hallo Michael,
da Christian hier nicht eingestiegen ist,
Ich sah keine Notwendigkeit mehr :)
Das, was das Forum im Moment langsam macht, ist weniger
Perl an sich,
Nun, Perl an sich macht auch ein Problem. Es ist schliesslich
nicht beliebig billig, den Perl-Interpreter zu starten, das
Script zu parsen und dann auch noch auszufuehren.
- Es müssen ständig XML-Strukturen geparsed werden, und
dafür wird ein Perl-Modul verwendet, das nicht so irre
schnell ist, dafür aber viel mehr kann, als das Forum
mit seinen relativ einfachen XML-Strukturen braucht.
Richtig.
- Da beliebig viele Benutzer gleichzeitig auf das Forum
zugreifen und dabei potentiell gleichzeitig posten
können, müssen viele der Zugriffe synchronisiert
werden.
Richtig.
- Zudem führt jedes Posting zur Änderung nicht nur des
kompletten Threads, sondern zudem noch zur Änderung der
Hauptdatei - also muß all dies während eines
Posting-Vorgangs gesperrt werden (deshalb behindern
mehrere Posting-Versuche einander).
Auch richtig.
- Und all dies auf einem Server, der ohnehin nicht
beliebig leistungsfähig ist
Richtig :)
und zudem ab und zu von
unfreundlichen Leuten mit Datenmüll beschossen wird.
Inzwischen fast dauerhaft *grummel*
Das neue Forum soll diese Probleme lösen:
a) Es soll ein neuer, selbst geschriebener (einfacher,
aber schneller) XML-Parser entstehen, der auf die
Bedürfnisse der Forums-Datenformate optimiert arbeitet.
(Ich glaube, lex und yacc dienen entweder als Grundlage
oder doch wenigstens als Ideengeber.)
Ehm, da hast du was missverstanden. lex und yacc habe ich
mir angeschaut fuer die Template-Engine. Das habe ich
inzwischen aber ganz anders geloest :) Der XML-Parser kann
beliebig langsam sein: ich starte den Forums-Prozess doch nur
ein einziges mal, danach ist alles im Hauptspeicher.
b) Die gesamte Kommunikationsstruktur soll geändert
werden. Bisher "reden" alle CGI-Skripte direkt mit der
Festplatte; künftig sollen die CGI-Skripte selbst nur
noch Clients sein, die Anforderungen an einen
zusätzlichen, permantent laufenden Forums-daemon
stellen (über Interprozeßkommunikation, z. B. ein
socket).
Richtig.
Dieser daemon serialisiert dabei alle Anforderungen,
Nein. Eine Serialisierung waere ja fuerchterlich lahmarschig.
Es laeuft etwas anders ab: fuer jede Connection wird ein
Thread gestartet. Der Thread behandelt die Session (eine
Session kann ja durchaus mehrere Anfragen enthalten). Jeder
Thread setzt einen Write-Lock auf die Struktur, mit der er
gerade arbeitet: lesende Zugriffe sind also weiterhin
moeglich. Wenn ein Posting gerade schreibenden Zugriff
braucht, etwa um eine Antwort einzufuegen, wird die Struktur
gerade nur zum umsetzen eines Pointers gesperrt; dass das nur
wenige ns dauert (wenn ueberhaupt), duerfte klar sein.
Fuer lesende Zugriffe auf die Haupt-Datei existiert ausserdem
noch ein Cache: die komplette Serialisierung der
Forums-Hauptdatei, die ja noetig ist, um die Liste durch den
Socket zu schicken, ist schon im Hauptspeicher fertig
zusammengestellt.
und es sind keinerlei gegenseitigen Sperren mehr
notwendig,
Doch, sind sie. Aber nur sehr kleine.
weil nur noch der daemon auf die
eigentlichen Datenobjekte zugreifen darf.
Richtig.
Außerdem kann der daemon natürlich das gesamte Forum im
Hauptspeicher halten (so viel kosten die paar hundert
Dateien ja nicht an RAM),
Etwa 6MB kosten sie :)
was erheblich an Festplattenzugriffen einspart;
Zum Lesen ist kein einziger HD-Zugriff noetig.
damit würde nicht nur das Posten, sondern ggf. auch das
Lesen schneller werden bzw. den Server weniger belasten.
In erster Linie optimiere ich das Forum auf lesende Zugriffe.
Aber auch das Posten duerfte wirklich schneller werden, ja.
Und die müssen nicht nur implementiert, sondern vor allem
auch gut getestet werden - bei der Kommunikation zwischen
dem daemon und seinen Clients darf nichts schief gehen,
sich nichts aufhängen usw. - wenn der daemon kaputt gehen
sollte, wäre das gesamte Forum lahm gelegt und müßte
manuell neu gestartet werden.
Nicht nur das, noch viel schlimmer: wenn der Forums-Server
sich aufhaengt und noch nicht alle neuen Postings geschrieben
wurden, kann es durchaus auch zu Datenverlusten oder
Inkonsistenzen kommen. Und das waere wirklich fatal.
Das doofe ist nur, eine C-Verion kann man nicht auf
jedem gehosteten Webserver installieren, oder kann man
das einfach wie andere Tools installieren?
Das sollte eigentlich kein Problem darstellen.
Für bestimmte häufig vorkommende Plattformen (Linux etc.)
kann man natürlich Binaries zum Download bereit stellen -
beim Apache ist das ja genauso, den übersetzt auch fast
niemand unter Windows selbst.
Bisher enthaelt aber der Forums-Source noch relativ viele
Plattformabhaengigkeiten (vor allem in der Makefile). Und ich
glaube nicht, dass das Forum jemals auf einem Windows-Rechner
laufen wird.
Gruesse,
CK
Hallo Christian,
Nun, Perl an sich macht auch ein Problem. Es ist
schliesslich nicht beliebig billig, den Perl-
Interpreter zu starten, das Script zu parsen und
dann auch noch auszufuehren.
aber dieses Problem würde sich ggf. auch ohne
Reimplementierunug des Forums lösen lassen
(mod_perl, mod_fastcgi?)
Das neue Forum soll diese Probleme lösen:
a) Es soll ein neuer, selbst geschriebener (einfacher,
aber schneller) XML-Parser entstehen,
Ehm, da hast du was missverstanden ...
Der XML-Parser kann beliebig langsam sein: ich
starte den Forums-Prozess doch nur ein einziges
mal, danach ist alles im Hauptspeicher.
Au ja, natürlich.
Dieser daemon serialisiert dabei alle
Anforderungen,
Nein. Eine Serialisierung waere ja fuerchterlich
lahmarschig.
Wenn die Clients über ein socket mit dem daemon reden,
dann serialisiert das ja automatisch.
Und wenn die gegenseitige Ausschlußphase dadurch,
daß nun alles im RAM liegt und viel schneller
adressierbar ist, nun sehr kurz wäre, würde es auch
schon erheblich schneller - ohne daß Du dafür ein
eigenes Locking-System erfinden müßtest.
Jeder Thread setzt einen Write-Lock auf die
Struktur, mit der er gerade arbeitet: lesende
Zugriffe sind also weiterhin moeglich.
Obwohl schreibende Zugriffe auch die Hauptdatei
ändern?
Daß Deine Lösung die bessere (und intellektuell
anspruchsvollere) ist, davon mußt Du mich nicht
überzeugen. ;-)
Fuer lesende Zugriffe auf die Haupt-Datei existiert
ausserdem noch ein Cache: die komplette
Serialisierung der Forums-Hauptdatei, die ja noetig
ist, um die Liste durch den Socket zu schicken, ist
schon im Hauptspeicher fertig zusammengestellt.
Ah - das ist der Trick: Quasi ein Transaktions-
mechanismus beim Posten und eine "alte" Sicht auf
die Hauptdatei mit hochperformantem Zugriff.
und es sind keinerlei gegenseitigen Sperren mehr
notwendig,
Doch, sind sie. Aber nur sehr kleine.
Mit Serialisierung wären sie ganz überflüssig gewesen.
Aber Dein Mechanismus ist bestimmt der bessere.
damit würde nicht nur das Posten, sondern ggf. auch das
Lesen schneller werden bzw. den Server weniger belasten.
In erster Linie optimiere ich das Forum auf lesende Zugriffe.
Das wäre jetzt die Stelle, um mal das Verhältnis
zwischen lesenden und postenden Zugriffen zu nennen ...
Aber auch das Posten duerfte wirklich schneller
werden, ja.
Und vor allem die lästige Meldung, daß man gerade
nicht posten darf, müßte völlig verschwinden.
sich nichts aufhängen usw. - wenn der daemon kaputt gehen
sollte, wäre das gesamte Forum lahm gelegt und müßte
manuell neu gestartet werden.
Nicht nur das, noch viel schlimmer: wenn der Forums-Server
sich aufhaengt und noch nicht alle neuen Postings geschrieben
wurden, kann es durchaus auch zu Datenverlusten oder
Inkonsistenzen kommen. Und das waere wirklich fatal.
Schreibt das neue Forum ab und zu (stündlich?) einen
checkpoint, um im Falle eines Crashs mit minimalem
Datenverlust wieder auf die Füße zu fallen?
Bisher enthaelt aber der Forums-Source noch relativ viele
Plattformabhaengigkeiten (vor allem in der Makefile). Und ich
glaube nicht, dass das Forum jemals auf einem Windows-Rechner
laufen wird.
Ich denke, es ginge dabei eher um diverse UNIX-
Plattformen, aber für Benutzer ohne shell-Zugang.
Viel Erfolg beim Programmieren
Michael
Hallo,
Bisher enthaelt aber der Forums-Source noch relativ viele
Plattformabhaengigkeiten (vor allem in der Makefile). Und ich
glaube nicht, dass das Forum jemals auf einem Windows-Rechner
laufen wird.
Ich denke, es ginge dabei eher um diverse UNIX-
Plattformen, aber für Benutzer ohne shell-Zugang.
Kleine dumme Zwischenfrage: Wie soll denn jemand diesen Dämon überhaupt starten können, wenn er keinen Shell-Zugang hat? Ich meine: Es gibt viele Anbieter, die Perl, PHP und MySQL aber keinen Shell-Zugang anbieten. Wie soll da dieser Dämon gestartet werden? (und sichergestellt werden, dass der laufen bleibt) Und wenn ein Anbieter z.B. seine Webserver in einem Cluster hat, wie wird das da gelöst?
Ich weiß: ich bin viel zu pessimistisch; an sich gefällt mir ja der Ansatz.
Viel Erfolg beim Programmieren
Wünsche ich auch,
Christian
Hoi,
Kleine dumme Zwischenfrage: Wie soll denn jemand diesen
Dämon überhaupt starten können, wenn er keinen Shell-Zugang
hat? Ich meine: Es gibt viele Anbieter, die Perl, PHP und
MySQL aber keinen Shell-Zugang anbieten. Wie soll da dieser
Dämon gestartet werden?
Ueber ein CGI-Script, dass...
(und sichergestellt werden, dass der laufen bleibt)
... ein Shell-Script startet, dass den Daemon startet. Wird
der Daemon (mit einem Fehler) beendet, wird er direkt neu
gestartet. Sozusagen ein Shell-Script in einem Endlos-Loop.
Und wenn ein Anbieter z.B. seine Webserver in einem
Cluster hat, wie wird das da gelöst?
Noch gar nicht. Wenn es erforderlich wird, werden wir uns
etwas einfallen lassen. Die Synchronisation von Daten
mehrerer Forums-Server duerfte kein sooo grosses Problem
darstellen.
Viel Erfolg beim Programmieren
Wünsche ich auch,
Danke.
Gruesse,
CK
hallo,
Kleine dumme Zwischenfrage: Wie soll denn jemand diesen Dämon überhaupt starten können, wenn er keinen Shell-Zugang hat? Ich meine: Es gibt viele Anbieter, die Perl, PHP und MySQL aber keinen Shell-Zugang anbieten. Wie soll da dieser Dämon gestartet werden? (und sichergestellt werden, dass der laufen bleibt) Und wenn ein Anbieter z.B. seine Webserver in einem Cluster hat, wie wird das da gelöst?
hmm... aber was ich bei deiner fragen nicht verstehe: warum sollten diese probleme uns interessieren?
grüße
thomas
Hallo,
Kleine dumme Zwischenfrage: Wie soll denn jemand diesen Dämon überhaupt starten können, wenn er keinen Shell-Zugang hat? Ich meine: Es gibt viele Anbieter, die Perl, PHP und MySQL aber keinen Shell-Zugang anbieten. Wie soll da dieser Dämon gestartet werden? (und sichergestellt werden, dass der laufen bleibt) Und wenn ein Anbieter z.B. seine Webserver in einem Cluster hat, wie wird das da gelöst?
hmm... aber was ich bei deiner fragen nicht verstehe: warum sollten diese probleme uns interessieren?
Euch müssen sie ja nicht interessieren ;-)
Aber ernsthaft:
Hier wurden die Vorteile von der Verwendung von C erläutert. Mich hat dann auch interessiert, wie/ob bestimmte unausweichliche Probleme bei dieser (zugegebenermaßen eleganten) "Architektur" in den Griff bekommen worden sind.
Grüße,
Christian
Hallo Christian,
hmm... aber was ich bei deiner fragen nicht verstehe: warum sollten diese probleme uns interessieren?
Euch müssen sie ja nicht interessieren ;-)
Aber ernsthaft:
Hier wurden die Vorteile von der Verwendung von C erläutert. Mich hat dann auch interessiert, wie/ob bestimmte unausweichliche Probleme bei dieser (zugegebenermaßen eleganten) "Architektur" in den Griff bekommen worden sind.
Ich sehe die von dir geschilderte unausweichliche Probleme nicht. Deshalb fragte ich auch nach.
"Es gibt viele Anbieter, die Perl, PHP und MySQL aber keinen Shell-Zugang anbieten."
Wir haben alle möglichen Zugänge zum Server. Wenn nötig auch den des "selbst Hand anlegens".
"Und wenn ein Anbieter z.B. seine Webserver in einem Cluster hat, wie wird das da gelöst?"
Wir haben unseren eigenen Server (was auch unser Eigentum ist) in den Räumen des Providers stehen.
Grüße
Thomas
use Mosche;
hmm... aber was ich bei deiner fragen nicht verstehe: warum sollten diese probleme uns interessieren?
Nana Thomas, immerhin war das alte Script ja auch als OpenSource verfügbar und es war (und ist) möglich, es auf einem anderen Server zu benutzen als auf dem TeamOne Server. Unter welche Lizenz CK sein Forum stellt, hat er bisher nicht gesagt (ich hoffe, es wird auch OpenSource), sollte es OS sein, dann sind Fragen danach, wie man Probleme unter bestimmten Umständen lösen kann, durchaus angebracht.
Solange CK also nicht Bekannt gibt, welche Lizenz er zu nutzen gedenkt, ist es für diejenigen, die das neue Forum auch privat einsetzen wollen, durchaus interessant, wie es in einem Cluster funktioniert. Warum auch nicht?
Ich hoffe, mein verworrener Gedankengang ist klar geworden :-)
use Tschoe qw(Matti);
Hallo Matti,
Solange CK also nicht Bekannt gibt, welche Lizenz er zu nutzen gedenkt,
The "Artistic License"
ist es für diejenigen, die das neue Forum auch privat einsetzen wollen,
durchaus interessant, wie es in einem Cluster funktioniert.
Tut es nicht (noch nicht? :)
Gruesse,
CK
Hallo Michael,
aber dieses Problem würde sich ggf. auch ohne
Reimplementierunug des Forums lösen lassen
(mod_perl, mod_fastcgi?)
Ja, wahrscheinlich schon. Es waere aber auch relativ viel
Arbeit.
Dieser daemon serialisiert dabei alle
Anforderungen,
Nein. Eine Serialisierung waere ja fuerchterlich
lahmarschig.
Wenn die Clients über ein socket mit dem daemon reden,
dann serialisiert das ja automatisch.
Warum?
Natuerlich sind mehrere, gleichzeitige Connects moeglich.
Und wenn die gegenseitige Ausschlußphase dadurch,
daß nun alles im RAM liegt und viel schneller
adressierbar ist, nun sehr kurz wäre, würde es auch
schon erheblich schneller - ohne daß Du dafür ein
eigenes Locking-System erfinden müßtest.
Das muss ich sowieso nicht :) Es gibt schliesslich Mutexes
und Conditionals.
Obwohl schreibende Zugriffe auch die Hauptdatei
ändern?
Ja.
Wie gesagt, meine Prioritaet liegt ganz eindeutig auf lesenden
Zugriffen. Die Schreiberlinge haben halt gegenueber den
Lesenden eine geringere Prioritaet.
Daß Deine Lösung die bessere (und intellektuell
anspruchsvollere) ist, davon mußt Du mich nicht
überzeugen. ;-)
Das wollte ich auch gar nicht, sorry.
Fuer lesende Zugriffe auf die Haupt-Datei existiert
ausserdem noch ein Cache: die komplette
Serialisierung der Forums-Hauptdatei, die ja noetig
ist, um die Liste durch den Socket zu schicken, ist
schon im Hauptspeicher fertig zusammengestellt.
Ah - das ist der Trick: Quasi ein Transaktions-
mechanismus beim Posten und eine "alte" Sicht auf
die Hauptdatei mit hochperformantem Zugriff.
Sozusagen, ja. Letztenendes ist es nur ein grosser, langer
String (puh, bin ich froh ueber meine
t_string-Implementierung :)
Mit Serialisierung wären sie ganz überflüssig gewesen.
Aber die Serialisierung waere zu einem (unnoetigen)
Flaschenhals geworden. Und da Locking nur innerhalb der
Prozessgrenzen notwendig ist...
Aber Dein Mechanismus ist bestimmt der bessere.
Hoffentlich.
Das wäre jetzt die Stelle, um mal das Verhältnis
zwischen lesenden und postenden Zugriffen zu nennen ...
Wir haben etwa 200 mal mehr lesende als schreibende
Zugriffe :)
Aber auch das Posten duerfte wirklich schneller
werden, ja.
Und vor allem die lästige Meldung, daß man gerade
nicht posten darf, müßte völlig verschwinden.
Ich hoffe es, ja.
Schreibt das neue Forum ab und zu (stündlich?) einen
checkpoint, um im Falle eines Crashs mit minimalem
Datenverlust wieder auf die Füße zu fallen?
Darueber bin ich mir noch nicht sicher. Ich tendiere halt
zwischen zwei Varianten: entweder feste Intervalle, in denen
alle geaenderten Threads neu geschrieben werden, oder halt
bei jeder Aenderung eines Threads wird er neu geschrieben.
Ich weiss halt noch nicht, was schneller ist -- muss ich
erst ausprobieren und Benchmarken.
Ich denke, es ginge dabei eher um diverse UNIX-
Plattformen, aber für Benutzer ohne shell-Zugang.
Das wird kein Problem darstellen. Ich muss halt lediglich
die Makefile ein wenig umschreiben.
Viel Erfolg beim Programmieren
Danke!
Gruesse,
CK
Sup!
Okay, jetzt habe ich aus dem CVS selfforum-cgi, -config, -data gesaugt... aber es fehlen Sachen wie z.B. "suche.pl", die in den Standard-Configfiles drinstehen.
Und wie werfe ich das Ding an, oder fehlen mir noch Dateien?
Gruesse,
Bio
Sup!
Laß' mich raten - selfforum-cgi kommt ins cgi-bin, selfforum-data wird irgendwo in den Webserver-Dateibaum gehängt, für das Verzeichnis wird SSI aktiviert, und dann funzt es?
Gruesse,
Bio
use Mosche;
Laß' mich raten - selfforum-cgi kommt ins cgi-bin, selfforum-data wird irgendwo in den Webserver-Dateibaum gehängt, für das Verzeichnis wird SSI aktiviert, und dann funzt es?
selfforum-cgi ist das cgi-bin-Verzeichnis (jedenfalls bei der 0.98), darin befinden sich die Verzeichnisse 'shared' und 'user'. 'data' kommt irgendwohin außerhalb des Document-Roots, und die (index|neu).shtml kommt in den Doc-Root.
Angepasst werden musste die Datei cgi-bin/user/config/common.xml, dann sollte alles funktionieren.
Siehe auch: http://sourceforge.net/mailarchive/forum.php?thread_id=57459&forum_id=1982
Diese Angaben beziehen sich auch auf 0.98.
use Tschoe qw(Matti);
Hi Ritter,
es fehlen Sachen wie z.B. "suche.pl", die in den Standard-Configfiles
drinstehen.
hm ... ein bißchen spärlich, die Information. Vielleicht kannst Du den
Kontext, in dem auf "suche.pl" verwiesen wird mitliefern?
Falls es sich dabei um "die" Self-Suche handeln sollte - die ist defi-
nitiv ein eigenes "Produkt" (und meines Wissens nicht öffentlich zu-
gänglich), und sie besteht zudem aus einer ganzen Reihe von Programmen.
Und wie werfe ich das Ding an, oder fehlen mir noch Dateien?
Um die Adressierungstechnik für die hier verwendeten URLs zu bauen,
müßte m. E. das Skript zur Ausgabe der Forums-Hauptdatei im Apache als
"DirectoryDefault" des entsprechenen Verzeichnisses konfiguriert werden.
Viele Grüße
Michael
Um die Adressierungstechnik für die hier verwendeten URLs zu bauen,
müßte m. E. das Skript zur Ausgabe der Forums-Hauptdatei im Apache als
"DirectoryDefault" des entsprechenen Verzeichnisses konfiguriert werden.
http://www.google.de/search?q=site%3A.apache.org+DirectoryDefault
http://httpd.apache.org/docs/mod/mod_dir.html#directoryindex
Hallo Linksetzer,
http://www.google.de/search?q=site%3A.apache.org+DirectoryDefault
solche unnützen Links bitte bleiben lassen, danke.
http://httpd.apache.org/docs/mod/mod_dir.html#directoryindex
Der war okay - aber ich traue dem Ritter durchaus zu, anhand eines
Stichwortes selbst die Apache-Dokumentation zu lesen, die er ja auch
nachweislich offline zur Verfügung hat.
Viele Grüße
Michael
hi!
Und wie werfe ich das Ding an, oder fehlen mir noch Dateien?
Um die Adressierungstechnik für die hier verwendeten URLs zu bauen,
müßte m. E. das Skript zur Ausgabe der Forums-Hauptdatei im Apache
als "DirectoryDefault" des entsprechenen Verzeichnisses konfiguriert
werden.
Das geschieht durch eine SSI-Anweisung in der index.shtml, die im
passenden Verzeichnis liegt. Die Perl-Skripts liegen alle im CGI-
Verzeichnis. Alternative: mod_rewrite. Theoretisch könnte man aber
auch die entsprechenden Perl-Skripts direkt ausführen lassen, wenn
man ExecCGI für jedes Verzeichnis erlauben möchte.
bye, Frank!