GNU Octave lze nově používat ve webovém prohlížeči v JupyterLite s jádrem Xeus-Octave.
Od 3. do 16. listopadu proběhnou Dny AI 2025. V úterý 11. listopadu proběhne Open source AI day v Red Hatu v Brně.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 158 (pdf) a Hello World 28 (pdf).
Vývojáři GIMPu nově vydávají oficiální snap balíčky GIMPu. Jsou sestavovány přímo v jejich CI (Continuous Integration) systému.
Správce sbírky fotografií digiKam byl vydán ve verzi 8.8.0. Jedná se o převážně opravné vydání provázené aktualizacemi knihoven. Novinky zahrnují implicitní použití systémového barevného profilu monitoru, import/export hierarchie štítků, editační nástroj rozostření aj.
Steve Jobs a superpočítač Cray-1 budou vyobrazeny na pamětních jednodolarových mincích vyražených v příštím roce v rámci série Americká inovace. Série má 57 mincí, tj. 57 inovací. Poslední 4 mince budou vyraženy v roce 2032.
Byl zveřejněn průběžně aktualizovaný program konference OpenAlt 2025 o otevřeném softwaru a datech, IT bezpečnosti, DIY a IoT. Konference proběhne o víkendu 1. a 2. listopadu v prostorách FIT VUT v Brně. Vstup je zdarma.
Senát včera opětovně nepřijal návrh ústavního zákona, který měl do Listiny základních práv a svobod zakotvit právo občanů platit v hotovosti nebo být off-line. Návrh předložila skupina senátorů již v roce 2023. Senát dnes návrh neschválil, ale ani nezamítl. Pokud by ho přijal, dostala by ho k projednání Sněmovna a vyjádřila by se k němu vláda.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 13.0 (Mastodon). Forgejo je fork Gitei.
Společnost Eclypsium se na svém blogu rozepsala o bezpečnostním problému počítačů Framework. Jedná se o zranitelnost v UEFI umožňující útočníkům obejít Secure Boot.
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: