Das deutsche Python-Forum

Hallo!

Nachdem mein SQLite Programm letztens aus so viel Interesse getroffen ist, habe ich mir überlegt, SQLite mit einem Server zu verkuppeln, so wie andere Datenbanken z.B. MySQL oder PostgreSQL. Ich habe mit dem Autor von SQLite_on_sockets (dessen Ansatz auch sehr interessant ist) in Verbindung gesetzt und der hat einige Verbesserungsvorschlage gehabt. Jedoch ist mein Ansatz über XML-RPC und somit um einiges einfacher. Nur der Server braucht PySQLite 2, der Client kann ein beliebiges Python sein. Was noch praktischer ist, dass der Client nichtmal Python zu sein braucht, sondern man es über praktisch jede Programmiersprache ansprechen kann, die XML-RPC unterstützt. Somit ist der Client nur als "Beispiel/Referenz-Implementation" zu sehen, nicht als etwas untrennbar verbundenes.

Und derweil hier der Code:
SQLator Daemon
SQLator Client

Ich würde mich über Kommentare sehr freuen!

Hi Leonidas,

ich dachte mir schon, dass Du einen Server für SQLite zusammenbaust... Ich werde das Programm heute abend mal testen. Der XML-RPC Ansatz gefällt mir auch gut!

Allerdings ist das mit einem SQLite Server natürlich so eine Sache, denn schliesslich ist SQLite ja eine dateibasierte Datenbank. Sprich es sind keine simultanen DB Zugriffe möglich, da die DB-Datei beim Lese- oder Schreibzugriff gesperrt ist. Also nicht unbedingt für Multi-User Geschichten geeignet. Für den netzwerkweiten DB Zugriff auf SQLite ist das ganze aber natürlich super geeignet...

Tabellar

PS: SQLite gefällt mir immer besser...

tabellar hat geschrieben:ich dachte mir schon, dass Du einen Server für SQLite zusammenbaust... Ich werde das Programm heute abend mal testen. Der XML-RPC Ansatz gefällt mir auch gut!

Bin ich wirklich so vorhersehbar? Na gut, es stimmt schon, seitdem ich SQLite kenne hat mich die Möglichkeit gereizt, das Ding Netzwerkfähig zu machen.

Was die ganzen User-Sachen angeht ist das auch noch so eine Sache, denn in der aktuellen Version gibt es bis jetzt keine commits, also ist praktisch nur Lesezugriff gegeben. Eine weitere Sache ist natürlich noch die Authentifikation: da XML-RPC wie SOAP über HTTP gehen und somit Verbindungslos sind, müsste man überlegen, wie man überprüfen kann, ob ein User sich verbinden darf oder nicht? Man könnte Usernamen und Passwort bei jedem Request übergeben, aber eine andere, elegantere, Lösung wäre mir lieber. Man könnte sich informieren wie das bei Subversion und WebDAV gelöst ist..

also auf der WIN Seite funktioniert das ganze schon mal ganz gut. Auch interaktiv kann ich über die "server.execute" Methode auf SQLite zugreifen (Create Table, select... ). Allerdings funktioniert der interaktive Client Zugriff von meiner Gentoo-Linux Kiste auf das WIN Notey mit dem SQLator mit "server.execute(...)" nicht...

Ich dachte eigentlich, dass man bei XML-RPC IMMER XML Statements schicken muss...

Tabellar

tabellar hat geschrieben:also auf der WIN Seite funktioniert das ganze schon mal ganz gut. Auch interaktiv kann ich über die "server.execute" Methode auf SQLite zugreifen (Create Table, select... ). Allerdings funktioniert der interaktive Client Zugriff von meiner Gentoo-Linux Kiste auf das WIN Notey mit dem SQLator mit "server.execute(...)" nicht...

Das ist kein Problem. Denn das habe ich schon mal gelöst. Ich habe sqlatord.py aktualisiert, nun sollte es ok sein (habe es von meinem Router aus getestet, bei mir gehts nun). Jaja, es ist bei weitem noch nicht fertig, bis jetzt erinnert es ja eher an einen Proof-of-Concept.

tabellar hat geschrieben:Ich dachte eigentlich, dass man bei XML-RPC IMMER XML Statements schicken muss...

Was meinst du mit XML Statements? Das immer XML übertragen wird? Das stimmt ja auch, die Requests und Reponses werden ja auch in XML-Form übertragen, jedoch macht die xmlrpclib das praktisch "tranparent" so dass du auf jeder Seite nur Funktionaufrufe und Daten hast, jedoch kein XML mehr. Das finde ich sehr praktisch, da muss ich mich nicht mit XML ärgern.

Also, ich hab jetzt SQLaterC Zugriff von der Gentoo Linux Kiste auf das WIN Notey mit SQLaterD. Das ganze kommt mir aber sehr langsam vor, liegt das am XML parsen der xmlrpclib??? Vielleicht doch lieber über native XML das ganze machen ...

Leonidas hat geschrieben:Was die ganzen User-Sachen angeht ist das auch noch so eine Sache, denn in der aktuellen Version gibt es bis jetzt keine commits, also ist praktisch nur Lesezugriff gegeben. Eine weitere Sache ist natürlich noch die Authentifikation: da XML-RPC wie SOAP über HTTP gehen und somit Verbindungslos sind, müsste man überlegen, wie man überprüfen kann, ob ein User sich verbinden darf oder nicht? Man könnte Usernamen und Passwort bei jedem Request übergeben, aber eine andere, elegantere, Lösung wäre mir lieber.

Na ja, ein INSERT mit anschliessendem COMMIT wäre schon nicht schlecht Bei den User Geschichten wäre ev. auch ein Session Handling vorstellbar, so wie bei der CGI Programmierung... User,Password -> Session ID ... Mehrere Threads für die Client Behandlung wären natürlich auch noch ein Ding ...

Tabellar

PS: Ich kenn mich in der Server Programmierung nicht so aus, aber was wäre denn die schnellste Server Variante, um auf SQLite zuzugreifen ... Socket Geschichten???

tabellar hat geschrieben:Also, ich hab jetzt SQLaterC Zugriff von der Gentoo Linux Kiste auf das WIN Notey mit SQLaterD. Das ganze kommt mir aber sehr langsam vor, liegt das am XML parsen der xmlrpclib??? Vielleicht doch lieber über native XML das ganze machen ...

Nein, das liegt einfach daran, dass jeder Request von neuem eine Verbindung aufbauen musst, da das ja alles über HTTP läuft.

tabellar hat geschrieben:Na ja, ein INSERT mit anschliessendem COMMIT wäre schon nicht schlecht

Ja, man könnte auch überlegen eine Autocommit-Option zu machen.

tabellar hat geschrieben:Bei den User Geschichten wäre ev. auch ein Session Handling vorstellbar, so wie bei der CGI Programmierung... User,Password -> Session ID ... Mehrere Threads für die Client Behandlung wären natürlich auch noch ein Ding ...

Session handling.. naja, sowas wird leicht schnell kompliziert.

tabellar hat geschrieben:PS: Ich kenn mich in der Server Programmierung nicht so aus, aber was wäre denn die schnellste Server Variante, um auf SQLite zuzugreifen ... Socket Geschichten???

Denke schon, sockets mit asyncore mit dauernder Verbindung. Das wäre recht schnell, jedoch bin ich das letzte mal als ich mich an Sockets gewagt habe, kläglich gescheitert (und das war nur IRC).

Für den Bau von Netzwerkservern wäre vermutlich sowieso noch Twisted zur Auswahl, jedoch habe ich damit noch nichts gemacht und das soll recht "anders" sein..

Leonidas hat geschrieben:Denke schon, sockets mit asyncore mit dauernder Verbindung. Das wäre recht schnell, jedoch bin ich das letzte mal als ich mich an Sockets gewagt habe, kläglich gescheitert (und das war nur IRC).

Für den Bau von Netzwerkservern wäre vermutlich sowieso noch Twisted zur Auswahl, jedoch habe ich damit noch nichts gemacht und das soll recht "anders" sein..

Twisted Matrix Laboratories is a distributed group of open-source developers working on Twisted, an event-driven networking framework written in Python and licensed under the LGPL. Twisted supports TCP, UDP, SSL/TLS, multicast, Unix sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more.

Hm, Twisted scheint ja ein richtig grosses Packet zu sein... Ich bin gerade an einem Thema dran, wo ich einen richtig schnellen, threadsicheren Server mit vielen DB Zugriffen brauchen könnte, aber natürlich in Python. Es geht um "Reaktive Systeme" (EventHandling) und "Workflowmanagement" und entsprechend vielen DB Zugriffen. Vielleicht mach ich dazu mal einen Thread in "Showcase" oder "Ideen" auf. Gibt's vielleicht den einen oder anderen Interessenten ? Ich würd mich freuen !!!

Tabellar

Twisted wäre durchaus eine Möglichkeit, jedoch müssten dazu die Benutzer auch Twisted haben, was ich eigentlich lieber vermeiden würde. Ich verfolge zur Zeit eher den Ansatz: "First get it running. Then make it running good."

Zur Zeit würde ich dir vermutlich eher PostgreSQL raten, das soll angeblich ziemlich cool sein. Zudem ist es schon fertig

Leonidas hat geschrieben:Twisted wäre durchaus eine Möglichkeit, jedoch müssten dazu die Benutzer auch Twisted haben, was ich eigentlich lieber vermeiden würde. Ich verfolge zur Zeit eher den Ansatz: "First get it running. Then make it running good."

Geht mir genauso! Ich möchte auch lieber mit Python "Bordmitteln" arbeiten. Gerade "asyncore" macht auf mich einen guten Eindruck.

O'Reilly hat geschrieben: Das Modul asyncore stellt eine "reaktive" Socket-Implementierung zur Verfügung...

Speziell die Handle-Funktion "handle_read" wäre für eingehende Ereignisse/Nachrichten ideal.

Leonidas hat geschrieben: Zur Zeit würde ich dir vermutlich eher PostgreSQL raten, das soll angeblich ziemlich cool sein. Zudem ist es schon fertig

Ich hab ja PostgreSQL schon in Verwendung . Trotzdem brauch ich ja noch einen AppServer, der entsprechende Ereignisse/Nachrichten annimmt, in die DB (z.B. PostgreSQL) steckt, entsprechend verarbeitet und dann wieder an entsprechende Objekte weiterschickt. Das kann natürlich ein Webserver sein, muss es aber nicht . Für das Rapid Prototyping sind SQLite oder div. M$ Produkte ganz gut geeignet. Der PostgreSQL Server ist dann natürlich das ideale Backend.

Tabellar

Hi,

zum Thema SQLite Server hätte ich noch ein paar Gedanken:

Es geht um das schon weiter oben beschriebene Projekt von mir,
wo ich mich unter anderem viel mit Jabber und seinem Protokoll beschäftige.

Themen bzgl. dem SQLite Server sind ja wie folgt:

- XML-RPC Nachrichten Format
- User Authentifizierung
- Session Handling
- Verteilte Objekte (zB. SQlaterD.getUserProfile )
- SSL???

Wenn man nicht unbedingt das alles selber implementieren möchte, kann man sich von einem Jabber Server helfen lassen. Und zwar so, indem der SQLaterD zu einem SQLaterJabberAgent wird . Hab ich also einen Python Jabber Client Requester, der zB. via "RPC over Jabber" Anfragen an den SQLaterJabberAgent Responder schickt, kann dieser die Anfrage bearbeiten und z.B. die Daten aus der SQLite (oder anderen) DB auslesen und an den Python Jabber Client Requester zurückschicken.

Die User Authentifizierung, das Sessionhandling und die SSL Verbindung übernimmt komplett der Jabber Server... Ich hab schon diverse TestAgents, die das so in etwa können. Verteilte Systeme und die Kommunikation untereinander wird so relativ einfach möglich.

Jabber wird somit zur optimalen Schnittstelle...

Gruss
Tabellar

tabellar hat geschrieben:Es geht um das schon weiter oben beschriebene Projekt von mir,
wo ich mich unter anderem viel mit Jabber und seinem Protokoll beschäftige.

- XML-RPC Nachrichten Format
- User Authentifizierung
- Session Handling
- Verteilte Objekte (zB. SQlaterD.getUserProfile )
- SSL???

Letzteres lässt sich sehr schnell schon jetzt mit stunnel drumrumhacken, oder auch mit TLS Lite gescheit implementieren.

tabellar hat geschrieben:Wenn man nicht unbedingt das alles selber implementieren möchte, kann man sich von einem Jabber Server helfen lassen. Und zwar so, indem der SQLaterD zu einem SQLaterJabberAgent wird . Hab ich also einen Python Jabber Client Requester, der zB. via "RPC over Jabber" Anfragen an den SQLaterJabberAgent Responder schickt, kann dieser die Anfrage bearbeiten und z.B. die Daten aus der SQLite (oder anderen) DB auslesen und an den Python Jabber Client Requester zurückschicken.

Welche Lib benutzt du? Jabber.py ist recht alt und xmpppy mag meinen amessage-Server net

tabellar hat geschrieben:Die User Authentifizierung, das Sessionhandling und die SSL Verbindung übernimmt komplett der Jabber Server... Ich hab schon diverse TestAgents, die das so in etwa können. Verteilte Systeme und die Kommunikation untereinander wird so relativ einfach möglich.

Jabber wird somit zur optimalen Schnittstelle...

Stimmt, aber dann müssen die Clients auch alle XML-RPC und Jabber verstehen, dagegen sind die Anforderungen bei reinem XML-RPC wesentlich niedriger.

Übrigens, es heißt SQLator

Leonidas hat geschrieben:Welche Lib benutzt du? Jabber.py ist recht alt und xmpppy mag meinen amessage-Server net

Ich verwende die "Jabber.py" LIB mit "xmlstream.py". Das ganze ist zwar schon älter, aber was solls. Wenn man sich das ganze mal anschaut, dann stellt xmlstream lediglich die Socket Verbindung und den Datenstrom zur Verfügung. "Jabber.py" ist dann ein "Jabber Protokoll" Wrapper, der die (XML) Daten hübsch zugänglich macht. Alt oder nicht, sollte sich was am Jabber Protokoll ändern, kann man Jabber.py einfach erweitern.

Leonidas hat geschrieben:

tabellar hat geschrieben:Die User Authentifizierung, das Sessionhandling und die SSL Verbindung übernimmt komplett der Jabber Server... Ich hab schon diverse TestAgents, die das so in etwa können. Verteilte Systeme und die Kommunikation untereinander wird so relativ einfach möglich.

Jabber wird somit zur optimalen Schnittstelle...

Stimmt, aber dann müssen die Clients auch alle XML-RPC und Jabber verstehen, dagegen sind die Anforderungen bei reinem XML-RPC wesentlich niedriger.

Das ganze hält sich wirklich in Grenzen. Man muss RPC ja auch nicht 100% erfüllen, sondern man kann sich eine einfache, provisorische RPC Syntax ausdenken. Bei meinen "TestAgents" habe ich einen Message Handler eingerichtet, der einfach das "Body" Feld der Message ausliest und dann entsprechend weiter verarbeitet. Im Prinzip wäre es kein grosses Problem, zB. sowas in der Art zu übergeben: <rpc><message type="sql"><sqlcmd>Select * from tuser;</sqlcmd></rpc>. Mann könnte natürlich das ganze auch über das Subject Feld in der Message lösen, in etwa so:

Subject: message:sqlcommand
Body: select * from tuser;

Wenn man das ganze im Message Handler so verdrahtet, dass diese SQL Ausführung nur von der Jabber Id (JID) leonidas@jabber.python-forum.de
ausgeführt werden darf, ist das ganze schon fast perfekt. Der Respose kommt dann einfach als Message vom "SQLator Agent" zurück.

Das ganze wäre als Prototyp schnell erstellt (ca. 30-40 Zeilen). Die Reichweite und die Kapselung der Anwendung ist nicht zu unterschätzen. Möchte ein weitere User Zugriff auf den SQLator Agent, muss er lediglich am JabberServer registriert sein und entsprechende Rechte beim SQLator Agent zur Ausführung der SQL Commands haben ...

Leonidas hat geschrieben:Übrigens, es heißt SQLator

Sorry

Tabellar

tabellar hat geschrieben:Ich verwende die "Jabber.py" LIB mit "xmlstream.py". Das ganze ist zwar schon älter, aber was solls. [...] Alt oder nicht, sollte sich was am Jabber Protokoll ändern, kann man Jabber.py einfach erweitern.

Schon, nur warum an jabberpy rumschustern, wenn es das modernere xmpppy gibt. Der Entwicker hat mir versprochen, die Probleme mit amessage ab version 0.3 zu beheben. Hoffe ich mal.

Leonidas hat geschrieben:Das ganze hält sich wirklich in Grenzen. Man muss RPC ja auch nicht 100% erfüllen, sondern man kann sich eine einfache, provisorische RPC Syntax ausdenken.

Ja, schon, aber dann ist es kein XML-RPC und wird praktisch unvereinbar. Dann kann man auch gleich einen asyncore/Twisted-Server machen, bei dem die Verbindung dauernd aufrecht erhalten wird.

tabellar hat geschrieben:Wenn man das ganze im Message Handler so verdrahtet, dass diese SQL Ausführung nur von der Jabber Id (JID) leonidas@jabber.python-forum.de
ausgeführt werden darf, ist das ganze schon fast perfekt. Der Respose kommt dann einfach als Message vom "SQLator Agent" zurück.

Die Idee hat durchaus etwas

Meine Idee wäre folgendes: einen SQLatorD schreiben, der einfach nur Serverfunktionalität bereitstellt, also die Datenbank und ggf. auch User verwaltet. Daneben gäbe es noch mehrere Transport Layer, die auf diesen SQLatorD-Kern zugreift und dessen Dienste per XML-RPC oder Jabber oder eigenem, asyncore/Twisted-Protokoll nach außen anbietet.
Was aber hier zu lösen wäre, ist die Kommunikation zwischen Transport und Karn, aber dafür könnte man sicher etwas finden.

Tut mir leid, dass ich deswegen so einen Aufstand mache, jedoch habe ich mal einen IRC Bot geschrieben und dort später die Lib auswechselnt wollen. Das gab ein schreckliches durcheinander, deswegen würde ich sowas lieber im vorraus planen, statt dann später es zusammenflicken zu müssen. Denn eine gescheite Lösung nutzt mehr Leuten, denke ich.

grüße,
Leonidas

Leonidas hat geschrieben:Schon, nur warum an jabberpy rumschustern, wenn es das modernere xmpppy gibt. Der Entwicker hat mir versprochen, die Probleme mit amessage ab version 0.3 zu beheben. Hoffe ich mal.

Ich werd mir xmpppy mal anschauen. Jabberpy ist nunmal ausgereift und wird z.B. in "Programming Jabber" (O'Reily) verwendet. Ich verwende unseren privaten "JabberServer", der nur über SSL (443) erreicht werden kann. Den amessage Server verwende ich z.B. im Zusammenspiel mit FreeMind, damit ist in der derzeitigen Version Collaboration via Jabber Protokoll möglich.

Leonidas hat geschrieben:Meine Idee wäre folgendes: einen SQLatorD schreiben, der einfach nur Serverfunktionalität bereitstellt, also die Datenbank und ggf. auch User verwaltet. Daneben gäbe es noch mehrere Transport Layer, die auf diesen SQLatorD-Kern zugreift und dessen Dienste per XML-RPC oder Jabber oder eigenem, asyncore/Twisted-Protokoll nach außen anbietet.
Was aber hier zu lösen wäre, ist die Kommunikation zwischen Transport und Karn, aber dafür könnte man sicher etwas finden.

Wie gesagt, ich wollte Euch mal meine Gedanken und Tests mitteilen. Ich bin gerade eben an einem Thema dran, wo die Themen des Zugriffs und der Schnittstellen eher zweitrangig sind. Da muss ich erst noch ganz andere Dinge intern knacken. Ich sehe das ganze so, dass die Schnittstellen, egal ob Socket Verbindung (asynchore), Datei oder Jabber Schnittstellen eben NUR Interfaces sind. Es gibt dann eben trotzdem diverse andere interen Komponenten wie zB. einen Db (SQLite) Wrapper, Session oder Eventhandler, die dann die EIGENTLICHE Arbeit machen. Mit der angesprochenen Jabber Schnittstelle konnte ich eben sehr schnell mit einem Standard Jabber Client (JAJC, Exodus) auf den laufenden Pseudo Prototyp Server "internetweit" zugreifen. Ich seh ob er läuft (online) ist und entsprechende Meldungen oder Logs postet er mir an den entsprechenden Jabber Client, mit dem ich irgendwo im Internet angemeldet bin...

Also, um unabhängig zu sein, ist natürlich eine Lösung mit asynchore ideal. Hat man einen eigenen Jabber Server, kann man von dem die Dienste für die connections und die Userverwaltung der einzelnen "Agents" verwenden. Gerade bei der Agenten Entwicklung finde ich SQLite ideal, da es sehr klein und leistungsfähig ist und nicht unbedingt ein grosser Datenbank Server sein muss.

Leonidas hat geschrieben:Denn eine gescheite Lösung nutzt mehr Leuten, denke ich.

Eine gscheite und gschickte Lösung ist natürlich immer gut und natürlich anzustreben...

Tabellar

PS:
Das "Agententhema" (Webcams, Messgeräte, Kaffeemaschinen, Relaissteuerungen, virtuelle Firmen, etc.), verteilte Systeme und Collaboration (CSCW) im allgemeinen bewegen mich eben zur Zeit sehr ...

Hm, der vorige Beitrag von mir war wohl zu lange für das Forum und hat mich rausgeschmissen ...

Tabellar

tabellar hat geschrieben:Ich werd mir xmpppy mal anschauen. Jabberpy ist nunmal ausgereift und wird z.B. in "Programming Jabber" (O'Reily) verwendet. Ich verwende unseren privaten "JabberServer", der nur über SSL (443) erreicht werden kann. Den amessage Server verwende ich z.B. im Zusammenspiel mit FreeMind, damit ist in der derzeitigen Version Collaboration via Jabber Protokoll möglich.

Ich weiß, jedoch ist xmpppy eine Wieterentwicklung von Jabberpy, die die API so weit wie möglich beibehlaten möchte. In wie weit das gelungen ist, kann ich nicht beurteilen. Aber der Autor von xmpppy ist auch Entwickler bei Jabberpy.

tabellar hat geschrieben:Wie gesagt, ich wollte Euch mal meine Gedanken und Tests mitteilen. Ich bin gerade eben an einem Thema dran, wo die Themen des Zugriffs und der Schnittstellen eher zweitrangig sind. Da muss ich erst noch ganz andere Dinge intern knacken. Ich sehe das ganze so, dass die Schnittstellen, egal ob Socket Verbindung (asynchore), Datei oder Jabber Schnittstellen eben NUR Interfaces sind. Es gibt dann eben trotzdem diverse andere interen Komponenten wie zB. einen Db (SQLite) Wrapper, Session oder Eventhandler, die dann die EIGENTLICHE Arbeit machen. Mit der angesprochenen Jabber Schnittstelle konnte ich eben sehr schnell mit einem Standard Jabber Client (JAJC, Exodus) auf den laufenden Pseudo Prototyp Server "internetweit" zugreifen. Ich seh ob er läuft (online) ist und entsprechende Meldungen oder Logs postet er mir an den entsprechenden Jabber Client, mit dem ich irgendwo im Internet angemeldet bin...

Sicher, eine Klasse Idee. Jedoch gebe ich zu, dass ich mich mit der programmierung von Jabber-Programmen nicht auskenne.

tabellar hat geschrieben:Also, um unabhängig zu sein, ist natürlich eine Lösung mit asynchore ideal. Hat man einen eigenen Jabber Server, kann man von dem die Dienste für die connections und die Userverwaltung der einzelnen "Agents" verwenden. Gerade bei der Agenten Entwicklung finde ich SQLite ideal, da es sehr klein und leistungsfähig ist und nicht unbedingt ein grosser Datenbank Server sein muss.

Klar, aber dazu bräuchte man doch einen Jabber Server. Und wenn ich einen SQL Server brauche, dann sollte es doch keine Vorraussetzung sein, dass ich einen Jabber Server habe. VOr allem Erfordert ein Jabber Server natürlich auch wieder Administration.

tabellar hat geschrieben:Eine gscheite und gschickte Lösung ist natürlich immer gut und natürlich anzustreben...

Gut. Ich habe mir auch noch folgendes überlegt:

- Ein Kern (muss keine Netzwerkfähigkeiten beinhalten, sondern nur das bereitstellen was alle Transports brauchen (könnten), wie zum Beispiel eine Userdatenbank mit jeweiligen Rechten)
- Transports (greifen auf Kern zu, haben dort praktisch Superuserrechte, also dürfen sie alles und sie erlauben hat den Benutzern den Zugriff, oder eben nicht).
- Sonstiges: Vielleicht kann man die Userverwaltung auch noch auskoppeln.

Ich weiß, das habe ich schon mal angedeutet, aber jetzt etwas genauer.

Jetzt bleibt die Frage, wie greifen die Transports auf den Kern (oder das "Sonstige") zu:
Man könnte mit Threads und sowas wie Candygram arbeiten, das kann aber dank Threads kompliziert und fehleranfällig werden. Oder die Transports sind per sowas wie Pyro angeschlossen, aber dann müsste man die Geschwindigkeit dieser Lösung erstmal untersuchen.

Leonidas hat geschrieben:Gut. Ich habe mir auch noch folgendes überlegt:

- Ein Kern (muss keine Netzwerkfähigkeiten beinhalten, sondern nur das bereitstellen was alle Transports brauchen (könnten), wie zum Beispiel eine Userdatenbank mit jeweiligen Rechten)
- Transports (greifen auf Kern zu, haben dort praktisch Superuserrechte, also dürfen sie alles und sie erlauben hat den Benutzern den Zugriff, oder eben nicht).
- Sonstiges: Vielleicht kann man die Userverwaltung auch noch auskoppeln.


Jetzt bleibt die Frage, wie greifen die Transports auf den Kern (oder das "Sonstige") zu:

Wir kommen langsam an den Punkt, an dem ich gerade rumhirne ... Ich hab mit Deinem Namen "Transports" noch etwas Mühe... Aber der Reihe nach ... Ich orientiere mich bei meinem Thema zur Zeit stark an den Serverarchitekturen von Jabber und Asterisk (VoIP PBX). Die beiden Server sind äusserst flexibel in der Architektur ausgelegt und haben meiner Meinung nach eine grosse Zukunft vor sich. Beide Server haben das Hauptthema Kommunikation im weitesten Sinne.

Wenn ich den Vergleich hier ziehe, dann würde es so aussehen, dass wir hier sogenannte Service Komponenten und ein Transport Backbone haben . Auf dem Transport Backbone werden Nachrichten zwischen den einzelnen Services ausgetauscht.

Services wären also wie folgt:
- Data Manager
- User Manager
- client to server (c2s)
- Log Komp.

Transport Backbone [Kern]:
- Message Switch/Router
- Event Manager
- ...

Die Leute beim Jabber Projekt haben sich gesagt, warum das Rad nochmal erfinden? Aus diesem Grunde haben sie ihr Jabber Protokoll in XML implementiert, welches für die interne und externe Kommunikation verwendet wird. Der neue Jabberd2 Server ist sogar so stark skalierbar ausgelegt, dass alle internen ServiceComponents via TCP Sockets verbunden sind. Bei starker Last können somit einzelne ServComp auf andere Rechner "ausgelagert werden (zB. DB ServComp). Bei Asterisk wird der Nachfolger vom IAX2 (VoIP) Protokoll (-> XIAX) ebenfalls in XML implementiert sein.

Beim Überfliegen von Pyro habe ich gesehen, dass es auch ein ähnliches Transport Backbone zur Verfügung stellt. Bei meinem derzeitigen "Server-Prototypen" habe ich eben auch das XML Nachrichten Format zwischen den Services gewählt und bin damit sehr zufrieden. Alle XML Messages werden in der DB gespeichert und durch entsprechende Message/Event Bindings weiter geroutet (zur Zeit mit SQLite ). XML ist sehr flexibel und plattform- und programmiersprachenneutral.

Also, die Hauptknacknuss ist die Transportschicht zwischen den Services. Wie flexibel muss sie sein, wie schnell, wie stabil, DB Logging? Fremdmodule?

Gruss Tabellar

Noch eine kurze Ergänzung: Wenn man das ganze natürlich rein unter dem SQL Server Aspekt sieht, dann wäre der Ablauf natürlich so, dass eigentlich ein Modul wie "PySQLite2" auf den "SQLator" zugreift und somit eine DB API 2.0 Schnittstelle darstellt... Das wäre das klassische (Python) Vorgehen...

Tabellar

tabellar hat geschrieben:Services wären also wie folgt:
- Data Manager
- User Manager
- client to server (c2s)
- Log Komp.

Transport Backbone [Kern]:
- Message Switch/Router
- Event Manager
- ...

Das ist natürlich eine tolle Sache, nur wird sowas schnell kompliziert und je komplizierter, desto schwieriger und aufwendiger zu implementieren. Und Anfällig wird sowas auch gerne.

tabellar hat geschrieben:Also, die Hauptknacknuss ist die Transportschicht zwischen den Services. Wie flexibel muss sie sein, wie schnell, wie stabil, DB Logging? Fremdmodule?

Naja, die Transportschicht wäre, wenn alle Services auf einem Server laufen, recht stabil. Also mit der flexibilität sollte man auch nicht übertreiben, denn man kann sie ja erweitern, das ist das tolle an Python. Fremdmodule sind zu vermeiden (besonders C-Erweiterungen), aber wenn sie viel helfen ist das auch in Ordnung.