Administrace komentářů

XML-RPC je ciste serializace do textu, prenos a deserializace. Ma omezenou, ale celkem pouzitelnou mnozinu datovych typu - boolean, int, string, datetime, blob, pole, slovník… to bude asitak vsechno. Nemá žádnou variantu None.

SOAP je afaik funkcni nadmnozina ktera pridava spis standartizaci formatu volani. Nekde jsem dokonce videl xml-rpc knihovnu bavit se SOAP serverem.

JSON format je o neco min ukecany nez xml, ale pokud neplanujes velky objemy dat, prijde mi jednodussi sahnout po hotovym xml-rpc nez hledat json knihovnu (ve standartni knihovne zadna neni) a vyrabet si nad ni vlastni rpc. A i kdybys chtel velky vykon, tak bude lepsi sahnout treba po fastrpc, ktery je rychlejsi ceckova implementace tehoz. (disclaimer: v tomhle jsem zaujaty, protoze fastrpc je muj deni chleba )

Webovy server je celkem detail, jsou hotovy knihovny ktery ti podstrci file handle a o ostatni se postaraji. V pythonu je obecny socket server, xml-rpc knihovna ho obaluje a postara se o (de)serializaci.

Jestli to budes psat v pythonu tak bych rekl ze xml-rpc je jasna volba protoze je soucasti standartni knihovny. Serverova cast vypada zhruba tak, ze zaregistrujes normalni pythoni funkce aby byly viditelny pod nejakym jmenem, a pri zavolani dostanes data od klienta klasicky do argumentu funkce. Na klientu staci vytvorit objekt spojeni na server a funkce poskytovany serverem se pak jevi jako jeho metody. Podivej se do rtfm, jsou tam i priklady.

SSH je externi program ktery muze a nemusi spolupracovat, s prvnim je spousta prace, s druhym spousta problemu. SSL/TLS je knihovna kterou muzes zapojit primo do vlastniho kodu a nebyt tak zavisly na dalsim programu. Ma to ne uplne trivialni nastaveni kvuli certifikatum, ale koneckoncu spawnovat proces se ssh taky neni zadna sranda. Pokud jsi zvykly pouzivat v ssh klice misto hesel, nebudes mit problem, je to stejny princip. Pokud ne, radsi si honem zvykni