Qual è la scelta attuale per fare RPC in Python? [chiuso]

132

In realtà, ho lavorato un po 'con Pyro e RPyC, ma c'è più implementazione RPC di questi due. Possiamo farne un elenco?

Protocolli nativi basati su Python:

Framework RPC con molti protocolli sottostanti:

Spyne (vedi discorso lampo )

Framework basati su JSON-RPC:

SAPONE:

Framework basati su XML-RPC:

XMLRPC, utilizzando i moduli xmlrpclib e SimpleXMLRPCServer nella libreria standard.

Altri:

python rpc

— edomaur
fonte

3

Dipende davvero dal contesto. Internet? LAN? Sito web? Calcolo distribuito? Prototipo veloce? Larghezza di banda? Dimensione dei messaggi?

— ddaa,

@silentghost: fatto. Preferisco non impostare "wiki comunità" per impostazione predefinita, perché a volte mi sbaglio :) @ddaa: Any. Sto chiedendo di RPC in termini generali, se hanno dei pro / contro in contesti specifici, si prega di aggiungerli all'elenco.

— Edomaur,

Avevo bisogno di fare RPC "reale" un po 'di tempo fa (il tipo RFC 1050) e le scelte non mi hanno impressionato molto, quindi alla fine ho dovuto fare la maggior parte da solo. Se qualcuno ha una buona alternativa a questo, mi piacerebbe saperlo.

— Mattias Nilsson,

Per coloro che desiderano RPC da Python a Python - L'ultima versione di PyRo 4 non supporta SSL, ma PyRo 3 lo fa ancora - entrambi sono tutti-Python quindi supportano Python 2, Python 3, PyPy, Jython e IronPython. RPyc supporta SSL, mentre Circuits non lo menziona.

— RichVel,

39

XML-RPC fa parte della libreria standard Python:

Python 2: xmlrpclib e SimpleXMLRPCServer
Python 3: xmlrpc (sia client che server )

— marbs
fonte

Da +1 a XML-RPC per semplicità, anche considerando che SimpleXMLRPCServer non ha una corretta gestione degli errori.

— Denis Otkidach,

1

"Avviso Il modulo xmlrpc.server non è sicuro contro i dati maliziosi.", Quindi ha alcuni casi d'uso piuttosto limitati.

— Equidamoide,

1

@Equidamoid Se è necessario analizzare dati non attendibili o non autenticati, consultare docs.python.org/2/library/xml.html#xml-vulnerabilities

— AmaChefe

17

Apache Thrift è un'opzione RPC multilingue sviluppata su Facebook. Funziona su socket, le firme delle funzioni sono definite in file di testo in modo indipendente dalla lingua.

— RemcoGerlich
fonte

Thrift non supporta Python 3 non è ancora supportato, è un peccato

— Roberto,

Commento personale: la parsimonia è un incubo per la manutenzione. Non ho visto due distribuzioni Linux nemmeno usare flag di configurazione comparabili. Non molto tempo fa (quando ho creato 0.10.0 dal sorgente), la maggior parte delle funzionalità deve essere disabilitata per farla costruire su sistemi "esotici" come l'attuale Ubuntu, Debian o Fedora. Le modifiche al tipo di dati sotto il cofano rendono l'utilizzo del C ++ un casino di #ifdefs, e nei 12 anni di esistenza, non sono riusciti a convincersi che il loro software è pronto per una versione 1.0.0. Mi piace l'enorme quantità di lingue supportate, ma penso che questa sia la loro debolezza: cercare di fare troppo.

— Marcus Müller,

(Uso la parsimonia in un progetto GNU di medie dimensioni che mantengo. @Roberto, supporto alla parsimonia Py3, almeno per ora.)

— Marcus Müller,

Incoraggerei davvero le persone a pensare davvero se hai davvero bisogno di un framework cross-language che cerchi letteralmente di collegare PHP a C ++ a Java a Python a Erlang a Common Lisp a Haskell a Swift. Queste sono lingue diverse, per una ragione, e Thrift deve scendere a compromessi per trovare un denominatore comune. Direi che la stragrande maggioranza delle persone ha davvero solo bisogno di collegare 1 o 2 lingue diverse, e sarebbe preferibile un framework più sottile.

— Marcus Müller,

7

Da quando ho posto questa domanda, ho iniziato a usare python-symmetric-jsonrpc . È abbastanza buono, può essere utilizzato tra software Python e non Python e seguire lo standard JSON-RPC. Ma manca alcuni esempi.

— edomaur
fonte

6

Potresti provare Ladon. Serve contemporaneamente più protocolli server Web in modo da poter offrire una maggiore flessibilità sul lato client.

http://pypi.python.org/pypi/ladon

— Jakob
fonte

3

Ci sono alcuni tentativi di far funzionare SOAP con Python, ma non l'ho testato molto, quindi non posso dire se è buono o no.

SOAPy è un esempio.

— Mattias Nilsson
fonte

2

Dopo aver utilizzato la maggior parte dei framework SOAP e averne implementato uno per realizzare RPC basato sulla riflessione, il mio consiglio è semplice: non farlo. Se non hai bisogno di comunicazione inter-lingua + descrizioni di interfaccia indipendenti + mappatura a classi personalizzate, la complessità di SOAP sarà solo un mal di testa. Anche se hai bisogno di usarlo, avrai bisogno dell'esperienza per sapere quale sottoinsieme di SOAP è sicuro da usare.

— Ants Aasma,

3

SOAP è un incubo in generale e soprattutto in Python. Non usarlo se non sei costretto a farlo.

— Denis Otkidach,

4

La mia esperienza limitata con SOAP concorda con gli altri commenti qui. xmlrpc spesso fa tutto ciò di cui ho bisogno.

— Mattias Nilsson,

3

Stiamo sviluppando Versile Python (VPy), un'implementazione per python 2.6+ e 3.x di un nuovo framework ORB / RPC. Sono disponibili rilasci funzionali AGPL per revisione e test . VPy ha funzionalità Python native simili a PyRo e RPyC tramite un livello generale di oggetti nativi ( esempio di codice ). Il prodotto è progettato per l'interazione di oggetti remoti indipendente dalla piattaforma per implementazioni di Versile Platform .

Informativa completa: lavoro per l'azienda che sviluppa VPy.

— Versile
fonte

2

forse ZSI che implementa SOAP. Ho usato il generatore di stub e ha funzionato correttamente. L'unico problema che ho riscontrato riguarda il SOAP tramite HTTPS.

— Phil
fonte

1

Ti sei perso omniORB . Questa è un'implementazione CORBA abbastanza completa, quindi puoi anche usarla per parlare con altre lingue che hanno il supporto CORBA.

— Dave Kirby
fonte