Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »Potrebuju propojit dva programy pres sit. Budou z 99% psane v pythonu, mozna v C. Potrebuju neco co pujde vsude (jakykoli jazyk a jakykoliv operacni system). Chci aby to komunikovalo pres TCP.
Zabezpeceni chci resit SSH tunelem.
Jak se to da realizovat? Nadefinovat si nejake textove retezce? Treba CTI, ZAPIS, ULOZ, ... Na netu jsem nasel neco o RPC, XML-RPC a SOAP, jaky na to mate nazor? Potrebuju rozeznavat asi 50 ruznych udalosti.
textove retazce by som urcite zavrholCo je na nich tak spatneho?
pravdepodobne pouzil bud nejake standardne web service (najskor soap), alebo nejaku formu xml cez http (postovanie xml dat na nejaku adresu pomocou http/s)Proc pres http? Nebylo by lepsi, kdyby serverovy program poslouchal na svem vlastnim portu?
taktiez security by som asi neriesil cez tunely ale cez httpsV cem je to lepsi nez ssh tunel?
Dobre, rozhodl jsem se pro XML - je to asi nejlepsi reseni.
Je lepsi XML-RPC, nebo SOAP?
Jak je to s tim JSON?
Takze ten program musi svuj vlastni interni webovy server?
Co je spatneho na ssh? V linuxu je a ve win muzu pouzit plink (z putty).
None
), Python xmlrpclib
ho podporuje (v konstruktoru ServerProxy je potřeba nastavit allow_none=True
).
XML-RPC i SOAP standardně komunikují pomocí XML dokumentů posílaných protokolem HTTP. Raději upřesním, že SOAP nepoužívá pro komunikaci XML-RPC. Hlavní rozdíl SOAPu a XML-RPC je, že standard SOAP kromě samotného posílání zpráv zahrnuje i možnost popisu webové služby (názvy poskytovaných metod, parametry atd.) a možná ještě i další věci.
Modul json
je součástí standardní knihovny Pythonu od verze 2.6. S JSONem obecně v Pythonu nevidím problém. Je pravda, že XML-RPC ti zprávu samo přeloží (deserializuje) do příslušných datových typů (string, int, datetime, ...), ale JSON je takový jednodušší, někomu se líbí. Jinak, dokázal bych si představit i vlastní síťový protokol (tedy ty "nejake textove retezce", žádné HTTP nebo XML-RPC) založený na JSONu, tedy bez onoho "vynaliezanie kolesa".
FastRPC bych široké veřejnosti moc nedoporučoval, má několik nepříjemných vlastností. (I pro mě je to denní chleba.)
S doporučením XML-RPC souhlasím, za předpokladu, že model požadavek-odpověď je vhodný způsob komunikace pro vyvíjenou aplikaci (tzn. že není potřeba něco jako "push notifikace", asynchronní způsob komunikace apod.).
SOAP je výhodný v prostředí, které je na něj připraveno, pravděpodobně nějaké enterprise .Net nebo Javové frameworky; jinak si myslím, že je s tím spíš práce navíc.
"Takze ten program musi svuj vlastni interni webovy server? " - no, nějaký server tam být musí, a když bude použito XML-RPC, shodou okolností se bude jednat o webový server. Je ale otázka, zda XML-RPC server obsažený ve standardní knihovně Pythonu, tedy SimpleXMLRPCServer, je vhodný pro produkční nasazení... Snad ano.
S tím, že TLS/SSL je systémovější řešení než SSH tunelování souhlasím. Je to ale ještě jedna možnost - pokud se se SSH počítá vždy, programy by mohly komunikovat prostě standardním vstupem a výstupem, takové řešení není neobvyklé (používá např. subversion, rsync).
…FastRPC bych široké veřejnosti moc nedoporučoval, má několik nepříjemných vlastností. (I pro mě je to denní chleba.)…Klidne to rekni nahlas - za zpusob jakym pythoni fastrpc api resi datetime a boolean patri nekdo zastrelit
Diky moc za rady, nakonec jsem se rozhodnul pro XML-RPC.
Jeste mam dotaz ke strukture toho XML, to si mohu sam nadefinovat?
<?xml version="1.0" encoding='UTF-8'?> <abc> <soubor src="tux.jpg" alt='obrazek tuxe'/> <popis>obrazky <date>2010</date> </popis> </abc>
<?xml version="1.0" encoding='UTF-8'?> <abc> <soubor> <src>tux.jpg</src> <alt>obrazek tuxe</alt> </soubor> <popis>obrazky <date>2010</date> </popis> </abc>
Co je lepsi?
{"weight": 13.42}
a ono to samo pošle <struct><member><name>price</name><value><double>13.420000</double><value></member></struct>
, to tebe ale zajímat nemusí, ty při normálním používání XML-RPC s žádným XML do styku nepřijdeš (což je vlastně smysl celého XML-RPC).
def netServer(): var.server = var.AsyncXMLRPCServer(('', int(var.entryPylogLocalPCPort.get_text())), SimpleXMLRPCRequestHandler) var.server.logRequests = False #turn off logging - no messages printed out during processing requests var.server.allow_none = True # Register function #var.server.register_instance(var.FunctionServer()) var.server.register_function(getInfo) var.server.register_function(registerClientLog) var.server.register_function(removeClientLog) var.server.register_function(registerClientDX) var.server.register_function(removeClientDX) var.server.register_function(getAllDX) var.server.register_function(sendLogRow) var.server.register_function(_receiveLogRow) var.server.register_function(sendSpotDX) var.server.register_function(_receiveSpotDX) var.server.register_function(selectFromDB) var.server.register_function(selectListFromDB) var.server.register_function(insertToDB) var.server.register_function(deleteInDB) var.server.register_function(updateDB) var.server.register_introspection_functions() # run! var.server.serve_forever()Ta funkce netServer() běží jako samostatný thread. Bylo to velice jednoduché a funkční řešení. Klienti pak používají něco takového:
... var.clientLog = xmlrpclib.Server('http://' + var.clientLogAddress) pommsel = var.clientLog.getInfo() ...
Tiskni
Sdílej: