Byla vydána nová stabilní verze 6.1 (aktuálně 6.1.3035.51) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 114. Přehled novinek i s náhledy v příspěvku na blogu. Nový Vivaldi se pro Bing tváří jako Microsoft Edge (upravený User-Agent) a díky tomu v něm funguje Bing Chat. Vylepšeny byly Pracovní prostory (Workspaces). Podrobný přehled v Changelogu.
Linuxová distribuce ArchLabs Linux po šesti letech vývoje končí. Dobbie to zabalil.
David Tschumperlé v obšírném článku se spoustou náhledů shrnuje vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok a půl.
Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.
Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.
Alyssa Rosenzweig v příspěvku na blogu oznámila, že Asahi Linux už zvládá OpenGL 3.1. Dokončuje se podpora OpenGL ES 3.1. Dalším krokem bude Vulkan 1.0.
Intel nedávno představil a pod licencí SIL Open Font License (OFL) na GitHubu zveřejnil font Intel One Mono. Font je určen především pro zobrazování textu v emulátorech terminálu a vývojových prostředích (Přehled fontů s pevnou šířkou).
Na redditu byly publikovány zajímavé QR kódy vygenerované pomocí Stable Diffusion. Přehled použitého softwaru v článku na Ars Technica.
Byl vydán Mozilla Firefox 114.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Nově jsou také na Linuxu podporovány USB FIDO2/WebAuthn bezpečnostní klíče. WebTransport je ve výchozím stavu povolen. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 114 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána červnová aktualizace aneb verze 2023.06-1 linuxové distribuce OSMC (Open Source Media Center). Z novinek lze zdůraznit povýšení verze multimediálního centra Kodi na 20. Na léto je plánováno představení nového vlajkového zařízení Vero, jež nahradí Vero 4K +.
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: