Project: Webinterface II - 13. F4F II Erklärungen

AMRBOSIA60 :: Projekt Webinterface II - 12. PHPBB2 und PHPNUKE als Grundlage fuer Webinterface II ?
AMBROSIA60-Portal  Webinterface II Project
AMRBOSIA60 :: Projekt Webinterface II - 14. Forum oder Board?



- [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)

© 2003-2024 by Ulrich Schroeter   01581