XML Objektserialisierung für Python und Java
Hallo, kennt jemand ein Objektserialisierungsformat in XML, dass sowohl von Python als auch Java gelesen/geschrieben werden kann, möglichst schon mit fertigen Libraries zur Serialisierung / Deserialisierung auf beiden Seiten? Ich möchte ein paar Daten über eine asynchrone Schnittstelle zwischen Java und Python austauschen und der Kunde wünscht sich ein XML-Format, also kann ich nicht JSON oder YAML verwenden. Ich brauche nur Unterstützung für "normale" Datentypen, also ints, floats, strings, arrays und mappings (dicts) und Unicode- bzw. zumindest UTF-8-Support. Chris
Am 08.06.2010 16:23, schrieb Christopher Arndt:
Ich brauche nur Unterstützung für "normale" Datentypen, also ints, floats, strings, arrays und mappings (dicts) und Unicode- bzw. zumindest UTF-8-Support.
xmlrpc enthält einen Serialisierer für solche Typen. Wahrscheinlich läßt sich der auch direkt ansprechen, also ohne die remote-call Funktionalität. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
Am 08.06.2010 um 16:50 schrieb Hartmut Goebel:
Am 08.06.2010 16:23, schrieb Christopher Arndt:
Ich brauche nur Unterstützung für "normale" Datentypen, also ints, floats, strings, arrays und mappings (dicts) und Unicode- bzw. zumindest UTF-8-Support.
xmlrpc enthält einen Serialisierer für solche Typen. Wahrscheinlich läßt sich der auch direkt ansprechen, also ohne die remote-call Funktionalität.
Ja, xmlrpclib.dumps und loads. Diez
Am 08.06.2010 17:38, schrieb Diez B. Roggisch:
Am 08.06.2010 um 16:50 schrieb Hartmut Goebel:
Am 08.06.2010 16:23, schrieb Christopher Arndt:
Ich brauche nur Unterstützung für "normale" Datentypen, also ints, floats, strings, arrays und mappings (dicts) und Unicode- bzw. zumindest UTF-8-Support.
xmlrpc enthält einen Serialisierer für solche Typen. Wahrscheinlich läßt sich der auch direkt ansprechen, also ohne die remote-call Funktionalität.
Ja, xmlrpclib.dumps und loads.
Bei xmlrpclib.dumps muss der äußere Container immer ein Tuple sein, d.h. weder xmlrpclib.dumps(dict(foo='bar')) noch xmlrpclib.dumps([1, 2, 3]) ist erlaubt. Letzteres kann man verschmerzen aber Ersteres finde ich doch etwas doof, weil man nicht einfach eine Liste von Name/Wert-Paaren übergeben kann. Man kann natürlich einfach ein Tuple mit einem dict als einzigem Element übergeben, aber die Gegenseite muss dann natürlich wissen, die restlichen Parameter zu ignorieren. Vielleicht kann ich den Kunden ja doch noch überzeugen, einfach JSON zu nehmen. Chris
On Wednesday, June 09, 2010 11:22:25 Christopher Arndt wrote:
Am 08.06.2010 17:38, schrieb Diez B. Roggisch:
Am 08.06.2010 um 16:50 schrieb Hartmut Goebel:
Am 08.06.2010 16:23, schrieb Christopher Arndt:
Ich brauche nur Unterstützung für "normale" Datentypen, also ints, floats, strings, arrays und mappings (dicts) und Unicode- bzw. zumindest UTF-8-Support.
xmlrpc enthält einen Serialisierer für solche Typen. Wahrscheinlich läßt sich der auch direkt ansprechen, also ohne die remote-call Funktionalität.
Ja, xmlrpclib.dumps und loads.
Bei xmlrpclib.dumps muss der äußere Container immer ein Tuple sein, d.h. weder
xmlrpclib.dumps(dict(foo='bar'))
noch
xmlrpclib.dumps([1, 2, 3])
ist erlaubt. Letzteres kann man verschmerzen aber Ersteres finde ich doch etwas doof, weil man nicht einfach eine Liste von Name/Wert-Paaren übergeben kann. Man kann natürlich einfach ein Tuple mit einem dict als einzigem Element übergeben, aber die Gegenseite muss dann natürlich wissen, die restlichen Parameter zu ignorieren.
Vielleicht kann ich den Kunden ja doch noch überzeugen, einfach JSON zu nehmen.
Es waere dir zu wuenschen, denn zusaetzlich ist XML einfach unglaublich aufgeblaeht - wir haben intern mal Faktor 10 gegenueber JSON ermittelt, was natuerlich auch stark von den Daten abhaengt. Diez
Am 09.06.2010 11:22, schrieb Christopher Arndt:
Bei xmlrpclib.dumps muss der äußere Container immer ein Tuple sein, d.h. weder
Ich habe nur ein gesundes Halbwissen über xmlrpc, aber es erscheint mir logisch, dass ein Tupel übergeben wird: Das ist die Liste der Argumente für die aufzurufenden Funktion. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
Hartmut Goebel schrieb:
Am 09.06.2010 11:22, schrieb Christopher Arndt:
Bei xmlrpclib.dumps muss der äußere Container immer ein Tuple sein, d.h. weder
Ich habe nur ein gesundes Halbwissen über xmlrpc, aber es erscheint mir logisch, dass ein Tupel übergeben wird: Das ist die Liste der Argumente für die aufzurufenden Funktion.
Klar, aber da xmlrpc keine benannten Funktionsargumente (aka keyword args) unterstützt, hat man auf oberster Ebene nur anonyme Werte und das gefällt mir nicht. Chris
participants (3)
-
Christopher Arndt -
Diez B. Roggisch -
Hartmut Goebel