Project: Webinterface II - 13. F4F II Erklärungen
- [77] R24-077-FUTURE4FIDO.GER (2:244/1120) ----------------- FUTURE4FIDO.GER -
Msg : #1788 [968]
By : Torsten Bamberg 2:240/5832 Die 06 Jul 04 23:50
To : Knut Pfefferkorn
Subj : F4F II Erklärungen war:M-H-T-R-Index Relations
-------------------------------------------------------------------------------
Hallo Knut!
Dienstag, den 06. Juli 2004 21:38, Knut Pfefferkorn schrieb an Torsten Bamberg:
TB>> gespeichert. Zur Anzeige kommen dann php-skripte, welche vom Webserver
TB>> kommen.
KP> d.h. es läuft ein Script, welches die PKT in eine Datenbank speichert?
KP> Unabhängig vom Tosser?
Ja. Ich habe das ganze soweit zusammengeschrieben, das nur ein Script
'crongesteuert' laufen muss.
Das das ganze im groben funktioniert, kannst Du bei Harald und bei mir auf den
Webseiten sehen.
TB>> Die Nachteile:
TB>> - Der Rechner braucht _viel_ Speicher.
KP> wofür eigentlich? Die Datenbank?
Unter anderem. Apache baut je nach Konfiguration und Belastung/Auslastung
zusätzliche 'Instanzen' auf. Hier laufen zzt 6 Apache-pid mit jeweils 22,8 Mb,
Mysql ist da noch freigiebiger, hier zzt 4 pid a 37 Mb.
Also sind schon mal eben 285 MB weg.
TB>> - Als Node lese ich meine Nachrichten doppelt. Um genau dies zu
TB>> unterbinden, ist dann erst ein Zugriff auf die vorhandene Messagebase
TB>> notwendig, die Änderung der Lastreadpointer. Bei genau diesem
TB>> (gegenüber dem Gesamtkonzept winzigen Funktion) sind die Meinungen
TB>> eher unterschiedlich.
KP> Hmm. Ist schon mal jemand auf die Idee gekommen, die Squish-API, oder
KP> smapi oder was es für die anderen Systeme gibt, so zu modifizieren, dass
KP> die Daten nicht in Dateien, sondern in einer Datenbank gespeichert werden?
Ja, das war eigentlich die Ursprungs-Idee. 'Einfach' die vorhandene Msg-Base
und FileBase zu nehmen, und das ganze httpd fähig aufzubereiten.
Allerdings würde dies durch die Vielfalt der unterschiedlichen Systeme ewig
dauern, und, dann wäre auch nicht sicher, das es in fast jeder Umgebung läuft.
Meine eigenen Experimente mit der Squish-api vor dem F4F II Projekt waren
dahingehend, allerdings habe ich mir immer mehr Fehler reingebaut, als dass es
etwas gebracht hat.
Allein das Fehlersuchen beim Husky-Projekt dauert ja schon ewig, und von
'sauber' laufen kann man ja nicht sprechen. ;-)
Und nun sollen alle offenen Api's in einem Projekt untergebracht werden?
Eine Arbeit für die nächsten Jahrhunderte. ;-)
*.pkt als Transferformat zu nutzen, war da der kleinste gemeinsame Nenner.
KP> Für die smapi und MySQL würde ich mir das sogar zutrauen, allerdings fehlt
KP> mir da im Moment die Zeit :-(
Bastel mal zu. Einbauen geht immer. ;-)
Und mit der fehlenden Zeit hast nicht nur Du zu kämpfen. :-(
By/2 Torsten
--- GoldED/2 3.0.1
* Origin: a strange kind of message... (2:240/5832)
