SQLite Server

[tabellar]

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

Tabellar

[Leonidas]

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.

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.

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.

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.

[tabellar]

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

[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

[Leonidas]

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.

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.

[tabellar]

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.

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.

Mit "Transportschicht" habe ich nicht unbedingt damit gemeint, dass die Services auf unterschiedlichen Rechnern laufen, sonder wie der Aufruf von Funktionen innerhalb des Programmes gehandelt wird. Sprich, ob hard codiert oder "etwas flexibler". Also gut, bleiben wir einfach .

Mich würde eine "Server Schnittstelle" mit asyncore interessieren. Das kann auch ruhig in Richtung SimpleAsyncHTTP Modul gehen... Funktioniert das Senden und Empfangen von "Client Daten", könnte man PySqlite2 als DB API dazwischen schalten (wie Du es ja bereits beim SQLator v0.0.0.1 schon gemacht hast). Bei Bedarf kann dann ein Programm Paket integriert werden, das die User- und IP Verwaltung übernimmt, z.B. in separaten Tabellen oder in einfachen Text (XML) Files.

Programmteile:
- client/Server Paket (asyncore)
- Kern / Main Paket
- pysqlite2 DB API 2.0 Modul
- user/ip Paket

Hast Du schon asyncore Erfahrungen?

Gruss Tabellar

[Leonidas]

Hast Du schon asyncore Erfahrungen?

Nein, aber ich vermute das wäre auch ein Fall für asynchat.
Ich könnte schon etwas testen, jedoch habe ich mit Netzwerkprogrammierung "am socket" eher schlechte Erfahrungen gemacht.. warscheinlich bin ich zu doof dafür.

[tabellar]

Die Sache hat mir keine Ruhe gelassen. Ich glaub, wir haben jetzt die kleinste und einfachste Form eines TCP-Socket Deamons :

Weitere Schritte:
- Sessionhandling für einzelne Clientanfragen
- Erhöhung des Buffers für Datenübertragungen > 1024 --> [erledigt]
- User Authorizierung
- Command Line Interface (CLI) Befehlssatz festlegen
- Erhöhung der Funktionalität des SQLatorD -> select, asyncore, asynchat, etc.


[SQLatorD]

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-24: A quick dirty TCP-Socket server for SQLite by Tabellar
2005-06-13: A XML-RPC server for the SQLite database by Leonidas
"""

import socket
from pysqlite2 import dbapi2 as sqlite

class SQLator(object):
   def __init__(self):
       self.port=8082
       self.dbfile="testdb.sqlite"
       try: 
         self.con=sqlite.connect(self.dbfile)
         print "SQLiteDB '" + self.dbfile + "' connected..."
       except:
         print "SQLiteDB " + self.dbfile + " connection failed..."

   def run(self):
       """---"""
       self.run=1
       self.sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
       self.sock.bind(("",self.port))
       print "SQLatorD waiting on port:", self.port
       
       while self.run:
           data,addr = self.sock.recvfrom(1024)
           #addr=Tupel ("text",portnr)         
           try:
             result=self.sqlExecute(data)
             print str(result)
             self.sendData(str(result),addr)
           except:
             print "Abfragefehler..."
             self.sendData("Abfragefehler...",addr)
     
   def sqlExecute(self,sql):
       cur=self.con.cursor()
       cur.execute(sql)
       resultList=cur.fetchall()
       self.con.commit()
       return resultList

   def sendData(self,data,addr):
       BUFSIZE = 1024
       while data:
             self.sock.sendto(data[:BUFSIZE], addr)
             data = data[BUFSIZE:]

def main():
    sqls=SQLator()
    sqls.run()

if __name__ == '__main__':
    main()

[SQLatorC]

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorC - the SQLator client
2005-06-24: A TCP-Socket client for the SQLator Daemon by Tabellar   
2005-06-13: A client for the SQLator Daemon, for using SQLite over network by Leonidas
"""

import socket,sys

port = 8082
host = "localhost"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 0))

intro = """SQLator remote shell
Enter ".help" for instructions"""

def dotparse(command):
    if command == 'quit':
        s.close()
        sys.exit()
    elif command == 'help':
        help()
    else:
        print 'No such command'

def help():
    helptext = {'.help' : 'Show this message', 
        '.quit' : 'Exit this program'}
    for key in helptext.keys():
        print key, helptext[key]
    #print textwrap.wrap(helptext)

def sendQuery(query):
    s.sendto(query, (host, port))
    data=''
    BUFSIZE=1024
    while BUFSIZE==1024:
          sockData=s.recv(1024)
          data=data+sockData
          BUFSIZE=len(sockData)
    return data


def main():
    print intro
    while True:
        query = raw_input('sqlator> ')
        if query.startswith('.'):
            # parse, without the dot
            dotparse(query[1:])
        else:
            print sendQuery(query)


if __name__ == '__main__':
    main()

    

C:\Programme\sqlator>SQLatorD.py
SQLiteDB 'testdb.sqlite' connected...
SQLatorD waiting on port: 8082
[(1, None, 0, u'test Workflow', 1, 0)]
[(1, None, 0, u'test Workflow', 1, 0)]

Gentux1 root # python SQlatorC.py
SQLator remote shell
Enter ".help" for instructions
sqlator> select * from twfInst;
[(1, None, 0, u'test Workflow', 1, 0)]
sqlator>

Ich hätte nie gedacht, dass ich das mal hinbekommen würde ... Erste Tests mit Zugriff von Linux auf Win via LAN und Linux auf WIN via VPN funktionierten problemlos... und vor allem ist das ganze auch ganz schön schnell...

Grüsse Tabellar

EDIT:
- SQL Befehle "INSERT, etc." funktionieren (SQL query wird immer commited...)
- Datenpakete > 1024 Bytes können nun übertragen werden (Test 73kB)

[querdenker]

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

Bei der Geschichte melde ich mal Interesse an.
Und hab auch noch einen Vorschlag für die DB: FirebirdSQL
Wir haben das DB-System im Dauereinsatz, Installation ist sowohl unter Win* als auch unter Unix einfach und klein (ca 10 MB).
Und die Python-Seite ist mit KInterbasdb auch gut unterstützt.

mfg, querdenker

[tabellar]

Bei der Geschichte melde ich mal Interesse an.
Und hab auch noch einen Vorschlag für die DB: FirebirdSQL
Wir haben das DB-System im Dauereinsatz, Installation ist sowohl unter Win* als auch unter Unix einfach und klein (ca 10 MB).
Und die Python-Seite ist mit KInterbasdb auch gut unterstützt.

mfg, querdenker

Hallo querdenker,

freut mich, dass Du Interesse an der Geschichte hast . Was speziell würde Dich an den von mir genannten Themen reizen? Firebird habe ich mal eine zeitlang beobachtet, aber nie wirklich eingesetzt. Die DB für das Backend ist auch erst in zweiter Linie von Bedeutung. Wie sagte schon Leonidas: "First get it running. Then make it running good." Ich denke, dass ich die nächsten Tage mal das Projekt im "Ideen" Bereich vorstelle. Das ganze ist ziemlich umfangreich und komplex, aber macht unheimlich viel Spass...

Gruss Tabellar

[tabellar]

- SQLatorD kann jetzt Datenpakete > 1024 Bytes versenden.
- SQLatorC kann jetzt Datenpakete > 1024 Bytes empfangen.

Tabellar

[querdenker]

@tabellar:
Interesse besteht eigentlich in allen 3 Bereichen, d.h. EventManagment, Workflow und DB.

Magst du mir mal ein wenig mehr darüber erzählen?

mfg, querdenker

[tabellar]

@tabellar:
Interesse besteht eigentlich in allen 3 Bereichen, d.h. EventManagment, Workflow und DB.

Magst du mir mal ein wenig mehr darüber erzählen?

mfg, querdenker

@querdenker:
Im Ideen Bereich hab ich mal ein bisschen was geschrieben...

@Leonidas:
Beim SQLator würdest Du ja gerne die Socket Geschichte mit XML-RPC verbinden. Das würde aber auch bedeuten, dass der Server entsprechende "Objektmethoden" zur Verfügung stellen müsste. Wie und was würdest Du Dir da vorstellen?

Tabellar

[Leonidas]

Beim SQLator würdest Du ja gerne die Socket Geschichte mit XML-RPC verbinden. Das würde aber auch bedeuten, dass der Server entsprechende "Objektmethoden" zur Verfügung stellen müsste. Wie und was würdest Du Dir da vorstellen?

Ich würde vermutlich einfach mal draufloshacken und gucken was gerade nötig ist. Wenn ich mal wieder Zeit habe (und diese Woche ist ziemlich stressig) könnte ich mal versuchen einen Proof-of-Concept zu schreiben.

Ich weiß, das Vorgehen ist vielleicht nicht besonders sauber, jedoch denke ich, dass ich mich so am besten in die Anforderungen und Probleme einarbeiten könnte.

[tabellar]

Ich würde vermutlich einfach mal draufloshacken und gucken was gerade nötig ist. Wenn ich mal wieder Zeit habe (und diese Woche ist ziemlich stressig) könnte ich mal versuchen einen Proof-of-Concept zu schreiben.

Ich hab schon mal "etwas" vorgegriffen und eine einfache XML-RPC-Socket Version gebastelt : Der XML-RPC SQLator verfügt jetzt über eine Objektmethode "selectCurFetchAll", die abgerufen werden kann.

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-30: A quick dirty XML-RPC Socket Server by Tabellar
2005-06-24: A quick dirty TCP-Socket server for SQLite by Tabellar
2005-06-13: A XML-RPC server for the SQLite database by Leonidas
"""

import socket
import xmlrpclib
from pysqlite2 import dbapi2 as sqlite

class SQLator(object):
   def __init__(self):
       self.port=8082
       self.dbfile="testdb.sqlite"
       try:
         self.con=sqlite.connect(self.dbfile)
         print "SQLiteDB '" + self.dbfile + "' connected..."
       except:
         print "SQLiteDB " + self.dbfile + " connection failed..."

   def run(self):
       """---"""
       self.run=1
       self.mainsock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
       self.mainsock.bind(("",self.port))
       self.mainsock.listen(1) #max 1 Verbindung gleichzeitig 
       print "SQLatorD waiting on port:", self.port
       
       while self.run:
           connection,address=self.mainsock.accept()
           print "Server connected by ",address
           while 1:
               data = connection.recv(1024)
               if not data: break
               print "received: ",data         
               params,method=xmlrpclib.loads(data)
               print "Method:",method
               print "Params:",params
            
               try:
                 if method=="selectCurFetchAll":
                    result=self.selectCurFetchAll(params)
                    response=xmlrpclib.dumps(((str(result[0])),(str(result[1]))),"selectCurFetchAll")
                    connection.send(response)
                 else:
                    connection.send("Methode nicht erkannt")

               except:
                 print "Abfragefehler..."
                 connection.send("Abfragefehler...")
           print "connection closed..."
           connection.close()

   def selectCurFetchAll(self,sqlquery):
       cur=self.con.cursor()
       cur.execute(str(sqlquery[0]))
       resultList=cur.fetchall()
       self.con.commit()
       return resultList


def main():
    sqls=SQLator()
    sqls.run()

if __name__ == '__main__':
    main() 

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-30: A simple quick dirty XML-RPC Socket Connection by Tabellar
"""

import socket
import xmlrpclib

#socket connection
port = 8082
host = "localhost"
con=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
con.connect((host,port))

#xml-rpc Input
Method="selectCurFetchAll"
Param=("select * from twfInst;")

#xmlrpclib "dumps"
request=xmlrpclib.dumps(((Param),),methodname=Method)

#xml-rpc-String
"""<?xml version='1.0'?>
<methodCall>
 <methodName>selectCurFetchAll</methodName>
  <params>
     <param>
       <value><string>select * from twfInstNode;</string></value>
     </param>
  </params>
</methodCall>"""

#Server XML-RPC Request
con.send(request)

#Server XML-RPC Response
data=con.recv(1024)

#xmlrpclib "loads"
param,method=xmlrpclib.loads(data)

#Print der Daten
print
print "Methode:", method
print "Input  :", Param
for i in param:
    print "Output :", i

#Connection schliessen
con.close()

C:\Programme\sqlator>RPCSQLatorC.py

Methode: selectCurFetchAll
Input : select * from twfInst;
Output : (1, None, 0, u'test Workflow', 1, 0)
Output : (2, None, 0, u'test', 123, 0)

Tabellar

[Leonidas]

Damit es nicht heißt ich spucke große Töne habe aber außer ein paar Codezeilen nichts zu bieten, habe ich mich irgendwann zwischen gestern und heute mal darangesetzt und SQLator stark ausgebaut. So habe ich meine Idee verschiedener Server umgesetzt.

Dazu gibt es ein(en) SQLatorB - Backbone/Backend, das die Datenbank öffnet und sie als Pyro-Objekt bereitstellt. Als weitere Ebene kommt SQLatorD - XML-RPC, die XML-RPC Version des Servers, sie entspricht dem Ur-Server, den ich hier vorgestellt habe. Als weiteres Schmankerl kam aber noch der SQLatorD - async hinzu, der alternativ zum XML-RPC Server verwendbar ist. Dieser Server ist eine Art XML-RPC mit persistenten Verbindungen und mit asyncore realisiert.
Zuletzt ist noch ein Client benötigt, dazu schlage ich den SQLatorC vor, dieser kann immernoch per 'echten' XML-RPC auf den Server zugreifen, als auch per async auf den neuen asyncore-Server (benötigt nur socket, die PySQLite-Bindungen sind auf dem Client unnötig).

Ich habe die IPC durch Pyro gelöst, weil Pyro eine Menge sehr praktischer Features hat, die auch in Zukunft praktisch sein könnten (wie z.B. ein Tuplespace). Also wird zum verwenden von SQLator noch Pyro (ich habe version 3.4 verwendet solange 3.5 noch in der Beta-Phase ist) benötigt, ich denke aber, das dies kein allzugroßes Problem sein sollte, denn Pyro ist unter MIT-Lizenz und 100% pures Python, somit kann man es auch zur Not mit ins Tarball packen.

Beim Schreiben des Servers mit asyncore ist mir aufgefallen, dass Sam Rushings Module großartig sind. Ich werde nie wieder einen Server in Python ohne asyncore (oder Twisted) schreiben, denn Event-gesteurte Netzwerkprogrammierung "fühlt" sich einfach viel besser an und die Programme schreiben sich wesentlich besser.

[tabellar]

Mir kommt das ganze ein bisschen überladen vor Mir ist noch nicht so ganz klar, warum du hier so viele Frameworks verwendest. Ich hab das ganze mal überflogen, aber noch nicht getestet. Ich bin kein Freund des endlosen Modul-Importierens...

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Die Asyncore/Asynchat Geschichte im SQLatorD gefällt mir ganz gut. Was mich ein wenig an deiner "allgemeinen XML-RPC" Verwendung stört, ist die allgemeine execute Funktion, die letztendlich die cur.fetchall() des Connection Objektes aufruft. Es gibt aber auch noch andere "Connection.Cursor Funktionen" ... Die Thematik habe ich bei meiner Socket/XML-RPC Version oben mal aufgezeigt.

Ich finde, das ganze sollte "leichtgewichtig" sein mit nicht zu vielen "import Modulen". Maximal Socket, Asyncore, Asynchat, PySQLite. Eine Alternative dazu wäre auch eine Variante mit SocketServer, Threading und Queue... (Clientverwaltung in jeweils einem eigenen Thread + Lock Mechanismus auf die Single-User-Datenbank ).

Ich muss mir das ganze aber auch noch mal genauer anschauen...
Tabellar

[Leonidas]

Mir kommt das ganze ein bisschen überladen vor Mir ist noch nicht so ganz klar, warum du hier so viele Frameworks verwendest. Ich hab das ganze mal überflogen, aber noch nicht getestet. Ich bin kein Freund des endlosen Modul-Importierens...

Ich verwende auußer PySQLite nur Pyro und das ist kein C-Modul, somit kann man es auch mit einpacken ohne dass es jegliche Probleme macht (und so groß ist pyro) auch nicht.

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen, die

Die Asyncore/Asynchat Geschichte im SQLatorD gefällt mir ganz gut. Was mich ein wenig an deiner "allgemeinen XML-RPC" Verwendung stört, ist die allgemeine execute Funktion, die letztendlich die cur.fetchall() des Connection Objektes aufruft. Es gibt aber auch noch andere "Connection.Cursor Funktionen" ... Die Thematik habe ich bei meiner Socket/XML-RPC Version oben mal aufgezeigt.

Ja, das war nur so zum testen ob es geht gedacht und kann sehr schnell korrigiert werden.

Ich finde, das ganze sollte "leichtgewichtig" sein mit nicht zu vielen "import Modulen". Maximal Socket, Asyncore, Asynchat, PySQLite. Eine Alternative dazu wäre auch eine Variante mit SocketServer, Threading und Queue... (Clientverwaltung in jeweils einem eigenen Thread + Lock Mechanismus auf die Single-User-Datenbank ).

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

[tabellar]

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen

Nun, auch wenn mehrere Server laufen würden, hätten diese auch nur ein "Connection" Objekt, welches sie von PySQLite erhalten. Sprich die Thematik für den Zugriff auf dieselbe DB wird dadurch nicht einfacher, sondern schwerer, weil die DB Zugriffe nicht mehr zentral gehandelt werden.

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Ich hab da schon ein paar ganz gute Beispiele ... Aber mir geht es gar nicht darum Pyro zu kopieren, sondern die Netzwerk Thematik besser verstehen zu lernen... Dies ist auch der Grund, warum ich mir andere Frameworks nicht gleich zu Nutze machen möchte.

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

Spassig ist dies ja allemal, und sich die Dinge anzuschauen bringt einen ja auch immer einen Schritt weiter...

Tabellar

[Leonidas]

Was genau soll Pyro bewirken? Das SQLatorB öffnet ja die DB und stellt anschliessend eine Pyro Objekt zur Verfügung. Reicht hier nicht einfach das Bereitstellen eines Connection Objektes(von pysqlite)???

Theoretisch schon, jedoch können aktuell auch mehrere Server gleichzeitig laufen ohne sich ins gehege zu kommen, mit einem einfach bereitgestellten con-Objekt wäre ich mir da gar nicht so sicher. Außerdem könnte SQLatorB zukünftig auch eine User-Datenbank bereitstellen

Nun, auch wenn mehrere Server laufen würden, hätten diese auch nur ein "Connection" Objekt, welches sie von PySQLite erhalten. Sprich die Thematik für den Zugriff auf dieselbe DB wird dadurch nicht einfacher, sondern schwerer, weil die DB Zugriffe nicht mehr zentral gehandelt werden.

Doch, die Zugriffe laufen alle über SQLiteB und werden somit zentral gehandhabt.

Den Socket/Queue und Threading server darfst du gerne schreiben.. womit du zwar die Funktionalität von Pyro kopierst, aber wenn du magst...

Ich hab da schon ein paar ganz gute Beispiele ... Aber mir geht es gar nicht darum Pyro zu kopieren, sondern die Netzwerk Thematik besser verstehen zu lernen... Dies ist auch der Grund, warum ich mir andere Frameworks nicht gleich zu Nutze machen möchte.

Naja, ich verwende ganz gerne Sachen die schon funktionieren und sich erprobt haben, besonders wenn man dabei keine Nachteile hat.

Gut dass ich dir nicht noch den xmlrpcd_twisted gezeigt habe, der ist kompatibel zum asyncore Server, benötigt aber noch Twisted *g* (und war dank Pyro und dem LayerServer in einer Stunde fertig).

Spassig ist dies ja allemal, und sich die Dinge anzuschauen bringt einen ja auch immer einen Schritt weiter...

Okay. Ich stell den online, wenn ich wieder zuhause bin. Du wirst sehen, dass der praktisch genauso funktioniert wie die async-Variante, also auch mit Factories und Protocols und XML-RPC kodierten Aufrufen. War ja auch praktisch ein Async-Port auf Twisted, mehr nicht.