SQLite Server

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 13. Juni 2005, 14:35

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!
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Montag 13. Juni 2005, 15:03

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... :P

Tabellar

PS: SQLite gefällt mir immer besser...
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 13. Juni 2005, 15:13

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..
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Montag 13. Juni 2005, 20:01

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... :cry:

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

Tabellar
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 13. Juni 2005, 20:29

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... :cry:
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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Montag 13. Juni 2005, 21:19

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 :wink: 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 ... :wink:

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???
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 14. Juni 2005, 14:17

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 :wink:
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 ... :wink:
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..
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Dienstag 14. Juni 2005, 18:02

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... :roll: 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 :wink: !!!

Tabellar
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 14. Juni 2005, 18:45

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 :)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Dienstag 14. Juni 2005, 19:13

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 :P . 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
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Dienstag 21. Juni 2005, 09:59

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 :shock: . 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... :P

Gruss
Tabellar
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 21. Juni 2005, 12:49

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 :shock: . 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... :P
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 ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Dienstag 21. Juni 2005, 13:37

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... :P
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 ... :P
Leonidas hat geschrieben:Übrigens, es heißt SQLator ;)
Sorry :oops:

Tabellar
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 21. Juni 2005, 18:09

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
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Gast

Dienstag 21. Juni 2005, 21:58

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... :wink:

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 ...
Antworten