Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
23.9.2019 18:01
Vykook | skóre: 23
| blog: Tomas
23.9.2019 18:19
Fluttershy, yay! | skóre: 93
| blog:
Ačkoliv, dost možná je na místě zamyslet se nad tím, co jsou zač kteří uživatelé.Dík za informaci. Hned je mi Chef sympatičtější. Rád budu používat software, který přispívá k lepší ochraně hranic. Taky je vidět, že úspěch se neodpouští, nejen u nás. Nebo spíš že ho neodpouštějí ti neúspěšní a defektní. Jen mi není jasné, jestli se tedy podle tebe má míchat vývoj softwaru a politika nebo ne. Nebo jen když se to shoduje s tvým pokřiveným pohledem na svět?
23.9.2019 18:49
Fluttershy, yay! | skóre: 93
| blog:
24.9.2019 23:45
Fluttershy, yay! | skóre: 93
| blog:
26.9.2019 11:09
Fluttershy, yay! | skóre: 93
| blog:
23.9.2019 21:44
Fluttershy, yay! | skóre: 93
| blog:
Tohle pojetí svobody, kde jsem to jenom viděl?
Aha, už vím.
There are two novels that can change a bookish fourteen-year old’s life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs.
—John Rogers
Takže to bychom měli.
V zásadě je to analogický lingvistický problém jako s demokracií, což je „vláda lidu“… podle některých však je to vláda – komu? lidu.
24.9.2019 07:04
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
24.9.2019 10:02
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
24.9.2019 14:34
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
25.9.2019 07:30
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
ROFL :DThere are two novels that can change a bookish fourteen-year old’s life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs.—John Rogers
24.9.2019 01:15
xkucf03 | skóre: 49
| blog: xkucf03
Tuhle kontinuitu otevřeného kódu nazvali free software.
Nikoli. Svobodný software je všechno možné včetně BSD, MIT, Apache 2.0 atd. Ta „kontinuita“, o které mluvíš, se nazývá copyleft.
24.9.2019 01:13
xkucf03 | skóre: 49
| blog: xkucf03
Tak vidis jaky paskvil to znasilnovani definice "svobody" GPL licenci nadelalo. Ted jsou lidi schopni rikat hlouposti na jine licence jako "nesvobodna"!
To není pravda. Jak GPL tak BSD jsou svobodné licence. Viz stránka Various Licenses and Comments about Them. Aby byla licence svobodná, tak musí vyhovovat definici svobodného softwaru tzn. zaručit čtyři základní svobody.
Jen ta první je copyleftová a zaručuje svobodu všem uživatelům provždy, zatímco ta druhá není a v tom případě se ta svoboda může v průběhu distribuce k uživatelům vytratit, takže i když byl v počátku software svobodný pod svobodnou licencí, k uživateli se tyto svobody nedostanou – uživatel dostane jen proprietární software nebo službu. Což je přesně důvod, proč tu máme copyleftové svobodné licence.
Aby byla licence svobodná, tak musí vyhovovat definici svobodného softwaru tzn. zaručit čtyři základní svobody.A sme zas u te polemiky. Nekdo si tu udela patent na definici "svobody" podle sve agendy a pak adhoc formuluje "svobodny software". Navic ty ctyri "svobody" jsou vysadou, atributem, ne prikazanim. A GPL nektere vynucuje prikazanim. Takze zas vyznam slova "svoboda" dostava na frak. Titulujte GPL tedy jako copyleftovou, nebo opensourcovou licenci, ale nedavejte ji nalepku "svobodna" protoze neni.
24.9.2019 11:03
Fluttershy, yay! | skóre: 93
| blog:
24.9.2019 13:41
Fluttershy, yay! | skóre: 93
| blog:
24.9.2019 14:01
xkucf03 | skóre: 49
| blog: xkucf03
Nikdo tě nenutí GPL software používat – prostě si ho nevšímej, když se ti nelíbí.
Autor má právo si vybrat licenci pro své dílo a stanovit pravidla pro jeho šíření. Když si někdo vybere copyleftovou licenci, tak je to proto, že chce dílo sdílet s těmi, kdo uznávají stejné hodnoty a kdo jsou připraveni sdílet i svoje příspěvky k tomuto dílu.
anarchisté chápou nutnost nějakých zákonů
Což by ale popíralo anarchii jako takovou resp. anarchie by tím zanikla. A pokud existenci nějakých zákonů/povinností připustíš, tak se to v principu nijak neliší od jakéhokoli jiného systému, který taky zavádí nějaká pravidla a povinnosti.
Pokud by se anarchii povedlo nastolit (resp. zničit původní řád), tak bude platit jen právo silnějšího – a ten vytvoří nový řád a hierarchii.
24.9.2019 23:36
Fluttershy, yay! | skóre: 93
| blog:
To neznamená, že anarchistická společnost se žádným způsobem nereguluje.Přesně to myslím. Ancap dystopie je děsivá představa psychopatů.
24.9.2019 15:16
Fluttershy, yay! | skóre: 93
| blog:
25.9.2019 12:12
Fluttershy, yay! | skóre: 93
| blog:
26.9.2019 10:34
Fluttershy, yay! | skóre: 93
| blog:
Zrovna tady bude problém trochu v něčem jiném než licencích. Copyleftové licence jsou samozřejmě správné, ale tady o ně až tak nejde.
Z webu (původně jednoduchá technologie přístupná komukoli – kdokoli ji mohl implementovat) se postupem času stalo něco obrovsky komplexního. Webový prohlížeč má dneska přes 20 milionů řádků kódu a to je takový objem práce, že to vlastně nikdo není schopný (nově) implementovat a všichni jsou víceméně nuceni používat ty stávající hromady kódu. Tohle je problém, na který tu upozorňuji už delší dobu. Web prostě shnil a odklonil se někam, kam neměl. Už jsem to popisoval někde jinde:
Redesign the Web: the Web evolved into total mess and even trivial tasks like reading a hypertext document or submitting a simple form require usage of overwhelmingly complex software (like 25 million lines of code). In this situation, nobody is able to implement a new (simpler, more secure) web browser and everybody is sentenced to reuse that millions of lines of code and just blindly believe into them. My opinion is that we need a new and better standard for simple tasks like reading a documentation, submitting a payment order to your bank, reading medical records or filling a tax form. Restricted (less complex) technology would fit much better to these tasks and would do better service than current web.
Ten přechod na jednodušší a kvalitnější technologii možný je – v první fázi se to může renderovat do HTML/CSS/JS zobrazovaného v současných komplexních prohlížečích a vedle toho můžou vznikat jednoduché a bezpečné implementace, které zobrazí jen ten nový standard.
26.9.2019 11:02
Fluttershy, yay! | skóre: 93
| blog:
26.9.2019 11:08
xkucf03 | skóre: 49
| blog: xkucf03
Tak na ty platformy nechoď a vytvoř něco lepšího…
26.9.2019 11:13
Fluttershy, yay! | skóre: 93
| blog:
26.9.2019 11:48
xkucf03 | skóre: 49
| blog: xkucf03
Předvádíš tu klasický levicový přístup – sám nejsi ochotný nic udělat, ale nařizovat něco druhým, to by se ti líbilo.
26.9.2019 11:54
Fluttershy, yay! | skóre: 93
| blog:
Z webu (původně jednoduchá technologie přístupná komukoli – kdokoli ji mohl implementovat) se postupem času stalo něco obrovsky komplexního. Webový prohlížeč má dneska přes 20 milionů řádků kódu a to je takový objem práce, že to vlastně nikdo není schopný (nově) implementovat a všichni jsou víceméně nuceni používat ty stávající hromady kódu. Tohle je problém, na který tu upozorňuji už delší dobu. Web prostě shnil a odklonil se někam, kam neměl.Jak problém, to je prostě vývoj. Web se stal složitým především proto, že se masivně rozšířil a používá se pro všechno možné. Ten vývoj nastal za poměrně krátký čas, takže ty technologie jsou vyvinuté tak trochu horempádem. Mimochodem, tvé oblíbené XML je také výsledkem tohohle procesu a IMO není o nic hezčí než ostatní webové technologie...
Ten přechod na jednodušší a kvalitnější technologii možný jeJakou jednodušší a kvalitnější technologii? Říct, že jsi schopen navrhnout technologii tak, aby pokryla featury moderního webu, ale přitom byla výrazně jednodušší a "hezčí", je IMO docela sebevědomé...
26.9.2019 13:20
xkucf03 | skóre: 49
| blog: xkucf03
Web se stal složitým především proto, že se masivně rozšířil a používá se pro všechno možné.
A to je právě otázka, jestli je vhodné mít jednu univerzální (a tím pádem složitou) technologii.
Mimochodem, tvé oblíbené XML je také výsledkem tohohle procesu a IMO není o nic hezčí než ostatní webové technologie...
Oproti webu je XML pořád nesrovnatelně lepší. Tady máš např. implementaci XML na méně než 4000 řádků: libucw. Nicméně i k tomu XML jsem se tu vyjadřoval v tom smyslu, že některé věci by z něj bylo dobré vyházet (DTD, entity). Pak by sis napsal parser za odpoledne. A generátor za hodinu (resp. ten napíšeš za hodinu už teď, protože generátor může podporovat jen podmnožinu, aby generoval platné XML).
Jak problém, to je prostě vývoj.
Problém webu vidím v tom, že i k řešení jednoduchých úloh potřebuješ dneska složitou technologii a těch 20-25 milionů řádků kódu. Jinak samozřejmě chápu, že pro složité úlohy je potřeba složitá technologie.
Jakou jednodušší a kvalitnější technologii? Říct, že jsi schopen navrhnout technologii tak, aby pokryla featury moderního webu, ale přitom byla výrazně jednodušší a "hezčí", je IMO docela sebevědomé...
Mě právě nezajímá „moderní web“ – přečti si, o čem píšu výše:
simple tasks like reading a documentation, submitting a payment order to your bank, reading medical records or filling a tax form
K tomu ti opravdu stačí technologie na úrovni přelomu 80. a 90. let.
Jestli si chce někdo ve webovém prohlížeči hrát multimediální hry nebo jím nahrazovat desktopové aplikace, tak ať si ten Firefox nebo Chromium používá – ale to je úplně jiná kategorie úloh.
Oproti webu je XML pořád nesrovnatelně lepší.To z mého pohledu rozhodně ne, HTML/XML považuju osobně za jeden z hlavních problémů webu...
Problém webu vidím v tom, že i k řešení jednoduchých úloh potřebuješ dneska složitou technologii a těch 20-25 milionů řádků kódu.No, to ale IMO platí o většině technologií, včetně třeba operačních systémů, textových editorů atd atd...simple tasks like reading a documentation, submitting a payment order to your bank, reading medical records or filling a tax formK tomu ti opravdu stačí technologie na úrovni přelomu 80. a 90. let.
28.9.2019 10:44
xkucf03 | skóre: 49
| blog: xkucf03
To z mého pohledu rozhodně ne, HTML/XML považuju osobně za jeden z hlavních problémů webu...
Co navrhuješ místo toho?
29.9.2019 21:53
xkucf03 | skóre: 49
| blog: xkucf03
Tak ono už se to do jistý míry nahrazuje. JS frameworky většinou integragují přímo s DOM API prohlížeče.
Aha, takže jakési proprietární RPC protokoly, kterými se natlačí data ze serveru do prohlížeče, tam se nad nimi dále čaruje a pak se to nějak vykreslí.
To jednak nevnímám moc jako pokrok a jednak bych řekl, že by bylo dobré rozlišovat webové stránky/dokumenty a webové aplikace.
Stránka by měla být deklarativní a neživá1. Přesto ale může být multimediální, kromě formátovaného textu může obsahovat odkazy na obrázky, videa nebo další objekty a ty se můžou vykreslovat v rámci té stránky. A na tohle jsem se právě ptal – co bys použil jako jazyk pro popis takových dokumentů.
Pak tu máme jednoduché webové aplikace, kde si vystačíš s vyplňováním formulářových polí, mačkáním tlačítek a přecházením mezi různými URL. Takový ten styl Webu 1.0, ale pro spoustu případů plně dostačující. Tady lze použít stejné prostředky jako v předchozím případě.
A nakonec tu jsou složité webové aplikace, které mají často ambice nahrazovat ty desktopové. Je otázka, jestli to má vůbec smysl… ale teď předpokládejme, že ano. Tady je logicky nějaký protokol pro RPC nebo obecněji posílání zpráv potřeba, s tím nemám v zásadě problém.
[1] sama od sebe nic nedělá, nepotřebuje obsahovat spustitelný kód (maximálně jako volitelnou funkcionalitu navíc, ale čitelná by měla být i bez toho)
Aha, takže jakési proprietární RPC protokoly, kterými se natlačí data ze serveru do prohlížeče, tam se nad nimi dále čaruje a pak se to nějak vykreslí.RPC protokoly? To snad ne. Typicky stačí API, které poskytuje data.
Stránka by měla být deklarativní a neživá[sama od sebe nic nedělá, nepotřebuje obsahovat spustitelný kód (...) A na tohle jsem se právě ptal – co bys použil jako jazyk pro popis takových dokumentů.Problém s (X)HTML je ten, že to nikdy tak úplně dokumenty nebyly, prakticky už od začátku to byly dokumenty smíchaný s uživatelským rozhraním. Strojově zpracovatelný to pořádně nebylo nikdy. A je otázka, jestli by to vůbec oddělit šlo a jestli to dává smysl. Na UI mi přijde zajímavý např. QML, ale je trochu moc objektový. Na dokumenty to asi není.
A nakonec tu jsou složité webové aplikace, které mají často ambice nahrazovat ty desktopové. Je otázka, jestli to má vůbec smysl… ale teď předpokládejme, že ano. Tady je logicky nějaký protokol pro RPC nebo obecněji posílání zpráv potřeba, s tím nemám v zásadě problém.RPC určitě ne, to je cesta do pekel IMO. Ani se to už moc nepoužívá dnes AFAIK. Mně se celkem líbí ten funkcionální přístup, kdy server poskytuje API, kde se servírují syrová data (ať už v jakýmkoli formátu) a kód, který je umí renderovat a je postaven na zásadach FP, tj. je to nějaká pipeline, do které jdou na jedné straně data a na druhé z ní leze DOM. Pro jednoduchý zobrazovač by to mohla být v zásadě i pure funkce, takže bys věděl, že to fakt nedělá nic jinýho než že to generuje DOM. Tohle má smysl IMO pro použití, kde je nějaká interaktivita a/nebo je potřeba nějaké fancy UI/zobrazování. Pro obyčejnej blogísek nebo něco takovýho je to možná overkill, tam asi stačí prostě načíst DOM serializovaný v XML a CSS, což je dané historicky jako standard. I když nijak moc pěkný to není. To, že dnes weby mývají API, mi přijde jako vylepšení i oproti tomu stavu na začátku webu.
30.9.2019 17:38
xkucf03 | skóre: 49
| blog: xkucf03
Problém s (X)HTML je ten, že to nikdy tak úplně dokumenty nebyly, prakticky už od začátku to byly dokumenty smíchaný s uživatelským rozhraním.
Ano, HTML je takové polovičaté řešení už od začátku. Míchá se tam do dat formátování (tučné či skloněné písmo atd.), ale to není chyba zastánců striktněšjího přístupu a XML, jako já. Přitom tam kdesi v pozadí ty dobré myšlenky jsou: HTML (data) + CSS (formátování).
Strojově zpracovatelný to pořádně nebylo nikdy. A je otázka, jestli by to vůbec oddělit šlo a jestli to dává smysl.
Oddělit to jde krásně: příklad – data jsou libovolné XML a k němu se připojí XSLT, které definuje, jak se to má zobrazit resp. jaké se z toho mají vygenerovat XHTML značky + CSS tomu dodá další úroveň formátování (díky němu i v tom vygenerovaném XHTML ty styly můžou být na jednom místě a nemusí se opakovat, i když to už je trochu jedno – šlo by to i bez CSS).
A to XML si otevřeš v prohlížeči (pokud autoři tvého prohlížeče tuto funkci dosud nerozbili). Viz příloha.
Samozřejmě by se to mělo vylepšit pročištěním (X)HTML a vyházením nepotřebných značek (víceméně stačí divy a spany nebo jen jeden kontejnerový typ + CSS třídy… případně by to CSS šlo aplikovat na libovolné XML, ale stále je žádoucí tam mít tu XSLT transformaci, protože struktura elementů surových dat může být samozřejmě jiná než struktura elementů určených k nastylování a zobrazení).
RPC určitě ne, to je cesta do pekel IMO. Ani se to už moc nepoužívá dnes AFAIK. RPC protokoly? To snad ne. Typicky stačí API, které poskytuje data.
A to API je co? Volají se tam nějaké vzdálené procedury/funkce, z prohlížeče na serveru, vrací nějaká data nebo na tom serveru provedou nějakou akci. Někteří se to snaží napasovat na pevně danou množinu procedur (GET, POST, PUT…) a říkají tomu REST API, ale nakonec většinou stejně dojdou k tomu, že potřebují na serveru volat nějaké obecné procedury/funkce, takže to stejně přiohnou, aby to jako RPC fungovalo, nebo na to kašlou od začátku a i když tomu říkají REST, tak stejně volají samé POST /api/něco-udělej. Pak je tu GraphQL, které je deklarativní (jako SQL), ale volání vzdálených procedur taky podporuje (mutations), protože bez toho RPC se moc vzdáleně běžící aplikace programovat nedají. Případně jsem tam psal o posílání zpráv (tam se používají WebSockety nebo long polling) a to je akorát obecnější způsob komunikace – buď to používáš asynchronně jako zprávy, nebo synchronně (požadavek-odpověď, takže nad tím zase nějakou tu formu RPC postavíš).
Mně se celkem líbí ten funkcionální přístup, kdy server poskytuje API, kde se servírují syrová data
Což je pořád do RPC. Rozdíle mezi procedurou a funkcí je akorát v tom, že funkce má návratovou hodnotu – ale procedura zase může mít výstupní parametry, takže tím funkce nahradíš, je to vlastně obecnější konstrukt.
(ať už v jakýmkoli formátu) a kód, který je umí renderovat a je postaven na zásadach FP, tj. je to nějaká pipeline, do které jdou na jedné straně data a na druhé z ní leze DOM.
Když už to dělat tímhle způsobem, tak mi přijde ztráta času tohle programovat v rámci aplikace, specificky pro ni. Vůbec to, jak si webaři dělí frontend a backend je degenerativní a zcestné. Pokud to tedy má být jedna aplikace běžící distribuovaně (část na serveru a část v prohlížeči), tak se o to má postarat framework typu Vaadin, kde k tomu programátor přistupuje tak, jako by aplikace distribuovaná nebyla, jako by běžela na jednom počítači – a o tu serializaci, deserializaci, RPC a vykreslování DOMu se postará framework.
Něco jiného je, když se rozhodneš udělat dvě či víc aplikací, jednu serverovou, která poskytuje API, a pak jednu nebo více klientských, které to API volají. Což má smysl tehdy, kdy chceš mít třeba webové, mobilní i desktopové klienty. A tam je nutným předpokladem mít dobře specifikované a stabilní API (popsané strojově čitelným způsobem a k němu samozřejmě generátory serverového i klientského kódu, takže to, co umělo WSDL před mnoha lety nebo ASN.1 či CORBA ještě mnohem dříve).
Pro obyčejnej blogísek nebo něco takovýho je to možná overkill, tam asi stačí prostě načíst DOM serializovaný v XML a CSS, což je dané historicky jako standard. I když nijak moc pěkný to není.
Proto říkám, že je dobré odlišovat aplikace a stránky/dokumenty.
HTML je sice ošklivé, ale pořád je to řádově lepší než imperativně generovat DOM na základě RPC odpovědí ze serveru. U stránky/dokumentu chci mít totiž možnost si ji uložit na disk a prohlížet si ji offline třeba i za dvacet let. Což jaksi s imperativním kódem volajícím RPC serveru, který v tu dobu už vůbec nemusí existovat, jaksi nejde.
30.9.2019 17:39
xkucf03 | skóre: 49
| blog: xkucf03
Přitom tam kdesi v pozadí ty dobré myšlenky jsou: HTML (data) + CSS (formátování).Chybí definice UI/layoutu. To CSS nikdy nemělo a v podstatě na to nic pořádnýho neexistuje.
Oddělit to jde krásně: příkladFunkcionální JS frameworky principielně dělají přesně tohle.
A to API je co? Volají se tam nějaké vzdálené procedury/funkce, z prohlížeče na serveru, vrací nějaká data nebo na tom serveru provedou nějakou akci. Někteří se to snaží napasovat na pevně danou množinu procedur (GET, POST, PUT…) a říkají tomu REST API, ale nakonec většinou stejně dojdou k tomu, že potřebují na serveru volat nějaké obecné procedury/funkce, takže to stejně přiohnou, aby to jako RPC fungovaloJak obecné procedury? V 95% případů to je akorát persistence dat. A i když to má být opravdu nějaká akce - třeba poslání e-mailu nebo něco - tak stejně dává větší smyslu na to mít nějakou frontu kde na jedné straně do toho uložíš obsah a na druhé straně si to něco vyzvedne a zpracuje. RPC je to asi ve stejném smyslu jako je RPC upload souboru na FTP server...
Což je pořád do RPC. Rozdíle mezi procedurou a funkcí je akorát v tom, že funkce má návratovou hodnotu – ale procedura zase může mít výstupní parametry, takže tím funkce nahradíš, je to vlastně obecnější konstrukt.Wtf. Ne. Měl jsem na mysli 'funkcionální' ve smyslu funkcionálního programování, kde na program se díváš jako na potrubí funkcí, kterými nějak tečou data a jsou přitom transformována. To XSLT je příklad něčeho takového (i když zrovna XSLT je z mého osobního pohledu hnus, principielně to ale odpovídá).
Něco jiného je, když se rozhodneš udělat dvě či víc aplikací, jednu serverovou, která poskytuje API, a pak jednu nebo více klientských, které to API volají.Přesně tak. Ta serverová část je často v podstatě pouze persistenční vrstva + delivery.
U stránky/dokumentu chci mít totiž možnost si ji uložit na disk a prohlížet si ji offline třeba i za dvacet let.Save Page WE. Ale bylo by fajn mít nějakou pořádnější nativní podporu.
Proto říkám, že je dobré odlišovat aplikace a stránky/dokumenty.Jenže to odlišení pořádně neexistuje. (Mrkni se na svůj blog například...)
30.9.2019 19:56
xkucf03 | skóre: 49
| blog: xkucf03
Chybí definice UI/layoutu. To CSS nikdy nemělo a v podstatě na to nic pořádnýho neexistuje.
To by ale mělo. Ten systém, který navrhuji je obecné XML + XLST/XQuery (které z toho vygeneruje něco jako XHTML, ale čistější) + CSS (resp. něco lepšího než CSS). Případně můžeš to XML a XSLT/XQuery vynechat, ale ochuzuješ se tím trochu o to oddělení čistých dat.
Resp. navrhuji, aby existovala nějaký jednoduchý jazyk pro popis dokumentů + jednoduchý jazyk pro základní stylování. Všechno ostatní nad tím můžou být volitelné součásti, ale vtip by byl v tom, že ty stránky (nebo jednoduché odesílání formulářů) by měly jít číst/používat i v triviálním prohlížeči, který by představoval zlomek komplexity dnešních WWW prohlížečů.
Funkcionální JS frameworky principielně dělají přesně tohle.
Akorát to není standard, což je škoda.
Jak obecné procedury? V 95% případů to je akorát persistence dat.
Některé aplikace sice fungují jako jednoduché UI nad databází, ale u normálních nebo složitějších aplikací tam máš většinou tolik triggerů, kontrol a transformací, že to je fakt spíš to RPC než persistence. Maximálně tam máš společný datový model, ale ani to většinou neplatí (ne všechno z DB chceš posílat do prohlížeče nebo to chceš mít uložené/strukturované jinak). V aplikacích se proto často rozlišují DTO (posílané ven skrze veřejné rozhraní) a entitní třídy (interně ukládané do databáze).
Wtf. Ne. Měl jsem na mysli 'funkcionální' ve smyslu funkcionálního programování, kde na program se díváš jako na potrubí funkcí, kterými nějak tečou data a jsou přitom transformována.
To chápu, ale když se bavíme o tom rozhraní, tak je jedno, jaké potrubí na těch dvou koncích máš. To rozhraní umožňuje volat vzdálené procedury/funkce. Pokud používáš omezenou pevně danou množinu funkcí, tak tomu můžeš říkat REST, ale obecně vzato je to pořád RPC.
To XSLT je příklad něčeho takového (i když zrovna XSLT je z mého osobního pohledu hnus, principielně to ale odpovídá).
Můžeš zkusit XQuery – to by se ti mohlo líbit i syntaxí. Ono i to XSLT je funkcionální, jen ta syntaxe hodně lidí odrazí. Svým způsobem je XSLT překonané (protože máme XQuery), ale některé věci se stále hodí a jdou v něm dělat elegantně, jednoduše. Zrovna teď v tom dělám to sane-software-manifesto – napsat si tu XSLT šablonu, která dělá přesně to, co chci, bylo výrazně jednodušší než hledat nějaký generátor webů, učit se jeho syntaxi a ohýbat ho pro svoje potřeby. Ale na složitější věci většinou víc se hodí to XQuery.
Ta serverová část je často v podstatě pouze persistenční vrstva + delivery.
Viz výše – obvykle tam bývá různá logika a k prosté persistenci to má dost daleko.
Pokud logiku na serveru nepotřebuješ, tak bych šel možná až k opačnému extrému – mít na serveru jen nějaký generický framework pro persistenci a nic tam neprogramovat. Ten framework by jen dokázal rozlišit přihlášeného uživatele a poskytoval by mu API k virtuálnímu souborovému systému nebo jednoduché databázi. A všechno bys programoval na straně klienta včetně třeba šifrování (může být odvozené od hesla uživatele, které se nebude posílat na server), takže by ani server neměl přístup k datům uživatele, sloužil by jen jako úložiště + třeba nějaké I/O (odesílání zpráv externím systémům nebo volání nějakého jiného RPC).
Save Page WE. Ale bylo by fajn mít nějakou pořádnější nativní podporu.
Budu muset vyzkoušet…
Jenže to odlišení pořádně neexistuje. (Mrkni se na svůj blog například...)
Co se ti nelíbí na mém blogu? Ten systém jsem právě psal tak, aby generoval stránky/dokumenty a ty šly číst i třeba v textových prohlížečích jako Lynx nebo Links2. A nejen číst, ale třeba i odesílat komentáře. V Lynxu to mám vyzkoušené, že to funguje. (v Linksu jsem to teď taky zkoušel, ale ten má zřejmě vypnuté cookies, takže tam jsem neprošel přes anti-spamovou kontrolu, ale v Lynxu cookies zapnuté jsou).
Jestli ti tam něco nefunguje nebo něco brání tomu, abys to mohl považovat za stránku/dokument (a ne aplikaci), tak dej vědět – to by byla chyba a rád to opravím.
Otestovat si svůj web v textovém prohlížeči je vlastně takové náhradní řešení k tomu návrhu, o kterém píšu na začátku tohoto komentáře. Tzn. donutí to člověka použít nějakou podmnožinu funkcí, kterou lze implementovat v jednoduchém prohlížeči. Ale kdyby existoval standard popisující takovou podmnožinu, tak by byla šance, že by se to víc rozšířilo a následně bys k provádění jednoduchých operací nebo prohlížení dokumentů nepotřeboval složitý software.
To by ale mělo. Ten systém, který navrhuji je obecné XML + XLST/XQuery (které z toho vygeneruje něco jako XHTML, ale čistější) + CSS (resp. něco lepšího než CSS). Případně můžeš to XML a XSLT/XQuery vynechat, ale ochuzuješ se tím trochu o to oddělení čistých dat.Ok, ale já s tím pravděpodobně nechci mít nic společného...
Některé aplikace sice fungují jako jednoduché UI nad databází, ale u normálních nebo složitějších aplikací tam máš většinou tolik triggerů, kontrol a transformací, že to je fakt spíš to RPC než persistence.Ne, fakt to RPC není. Transformace / triggery != RPC.
Pokud používáš omezenou pevně danou množinu funkcí, tak tomu můžeš říkat REST, ale obecně vzato je to pořád RPC. (...) Viz výše – obvykle tam bývá různá logika a k prosté persistenci to má dost daleko.Problém s uvažováním o tom jako o RPC je, že to je stále to samé OOP/imperativní uvažování á la Cobol. To, že na serveru může být libovolně netriviální logika neznamená, že musí mít RPC-like API.
Co se ti nelíbí na mém blogu?Nemam proti němu vůbec nic, akorát je to z mého pohledu je prostě aplikace
Konkrétně v tom, že obsah článku a další komponenty jako navigace, komentáře, vkládání komentářů atd. jsou smíchané dohromady v jednom formátu/médiu/whatever. Ten rozdíl oproti moderním webům IMO není kvalitativní, ale pouze kvantitativní. Prostě arbitrárně píchneš někam do roku 2003 a řekneš "Tady byla ta zlatá doba".
Mimochodem, víš jak fungují vevnitř (X)HTML formuláře? Viz 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
application/x-www-form-urlencoded a multipart/formdata . To je IMO pěknej humus.
1.10.2019 10:00
xkucf03 | skóre: 49
| blog: xkucf03
Ne, fakt to RPC není.
RPC není nějaká konkrétní technologie, je to obecný princip, který spočívá v tom, že voláš proceduru (subrutinu, funkci) na vzdáleném počítači. Nepředstavuj si pod tím nic mystického :-)
In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network)
Transformace / triggery != RPC.
Nemyslím tím databázové triggery, ale obecně nějaké akce, které se spouští při přijetí požadavku. A jde mi o to, že tam té logiky a transformací bývá tolik, že bych to opravdu nenazýval perzistentní vrstvou. Někde jsi to tu přirovnával k FTP, ale to je jiný případ: FTP se mapuje 1:1 na skutečné soubory na serveru. Nebo různé virtuální FS – i když jsou virtuální, tak respektují tu původní logiku a emulují to rozhraní tak, jako by se ukládaly soubory na disk tzn. když něco zapíši, tak bych měl být schopný přesně totéž zase přečíst na přesně té stejné cestě nebo když čtu víckrát z jednoho umístění, tak by tam mělo být pořád to samé (pokud to jiný proces nemění).
Teoreticky (správně) takhle funguje ten REST. Ale v praxi se často používá spíš tím RPC stylem, kde voláš jakési vzdálené procedury či funkce a není ze sémantiky toho rozhraní zřejmé, v jaké modifikace stavu a v jaké vedlejší efekty to vyústí – musíš si přečíst v dokumentaci (pokud existuje), že např. když uděláš POST /udělej-xy, tak pak můžeš udělat GET /něco-někde-jinde a tam si přečíst cosi, co je nějak vzdáleně odvozené z toho, co jsi volal před tím. Tohle už ani není REST, ale lidi tomu tak říkají a používají to tímhle způsobem. Podle mého je daleko férovější tomu říkat prostě RPC. Nemluvě o tom, že i to čtení často probíhá přes POST a posílají se tam vyhledávací kritéria/filtry/dotaz v těle požadavku.
Problém s uvažováním o tom jako o RPC je, že to je stále to samé OOP/imperativní uvažování á la Cobol. To, že na serveru může být libovolně netriviální logika neznamená, že musí mít RPC-like API.
Možná by stálo za to vysvětlit, co si představuješ pod „RPC-like API“, protože si zjevně pořád nějak nerozumíme a asi jen používáme stejná slova pro něco jiného.
akorát je to z mého pohledu je prostě aplikace
Ne, je to stránka/dokument. Když uděláš GET https://blog.frantovo.cz/c/377/, tak si ten dokument stáhneš, v těle odpovědi dostaneš text článku. Můžeš si to číst třeba curlem nebo telnetem – nepotřebuješ spouštět žádný můj kód (JavaScript není potřeba) k tomu, abys tu odpověď interpretoval – je to deklarativní neživý (sám od sebe nic nedělá) dokument.
Ano, je tam nějaká nabídka, patička atd. ale to je jako tiráž nebo záhlaví/zápatí v knize. Nedělá to z toho aplikaci. Knihu si prostě otevřeš a čteš si v ní sám písmenka, sám si v ní listuješ. Kdyby kniha byla aplikace, tak bys ji musel nejdřív zapojit do zásuvky nebo jí poskytnout jiné zdroje nebo třeba točit klikou a ta kniha by pak sama otáčela stránkami nebo vykreslovala písmenka pomocí nějakého mechanického displeje. Cítíš ten rozdíl? V jednom případě je to pasivní objekt v nějakém předem dohodnutém formátu, který jen čeká, až si ho někdo přečte. A v druhém případě je to nějaká aktivní entita, černá skříňka, kde je uvnitř skrytý nějaký mechanismus a navenek to má nějaké vstupy a výstupy.
Viz application/x-www-form-urlencoded a multipart/formdata . To je IMO pěknej humus.
Ano, vím, rád tyhle věci zkoumám, koukám dovnitř Wiresharkem nebo posílám požadavky telnetem :-)
Používám tam application/x-www-form-urlencoded, což je vlastně jednoduchý formát pro serializaci mapy. Neříkám, že je to bůhvíjak krásné, ale nemám s tím zásadní problém. Mimochodem ty internetové standardy často vznikají živelně a krásou neoplývají, vrší se nad sebe další a další, viz třeba kódování v e-mailových hlavičkách (předposlední komentář). Tam se ti na jednom řádku, v jednom poli setkají dokonce tři nebo čtyři kódování.
Možná by stálo za to vysvětlit, co si představuješ pod „RPC-like API“, protože si zjevně pořád nějak nerozumíme a asi jen používáme stejná slova pro něco jiného.Já na tom pojmu netrvám a popravdě třeba takový pojem 'REST' mi taky přijde dost vágní... Pro mě je důležitým rozdílem těsnost provázání. Klasické RPC si představuju tak, že ta klientská aplikace přímo zná jména metod v tom serverovém softwaru, parametry atd., taky to má víceméně instantní odezvu, resp. ne instantní, ale vázanou na to volání... IMO ta pointa toho REST-like rozhrání je volnější provázanost a větší nezávislost těch komponent. Plus také ten více FP-like model, kde místo volání metody a přijmutí výsledku vložíš nějaký data do nějaký trubky a výsledek se dostaví třeba někdy jindy v jiný trubce v rámci normálního datově-transformačního flow tý aplikace. A kolik tranformací, výpočtů nebo nějaký dalších akcí tam nastane je v podstatě už nesouvisející otázka. Pokud nevíš, co tím mám na mysli, mrkni na tenhle talk od Facebooku (jasně, Facebook je evil, nicméně tohle je IMO dobrý talk).
Ne, je to stránka/dokument. Když uděláš GET https://blog.frantovo.cz/c/377/, tak si ten dokument stáhneš, v těle odpovědi dostaneš text článku.
Text článku a taky interface pro navigaci tvého webu a pro posílání komentářů. Ta data toho článku od toho UI té aplikace spolehlivě neoddělim (obecně).
U té otázky, jestli potřebuju spouštět tvůj kód, popravdě moc nevidim, v čem je relevantní. Bezpečnost? Kritické RCE chyby a další chyby (soukromí atd.) byly v prohlížečích i jen s XHTML/CSS.
A v druhém případě je to nějaká aktivní entita, černá skříňka, kde je uvnitř skrytý nějaký mechanismus a navenek to má nějaké vstupy a výstupy.No, od toho je právě to REST API, abys měl přístup k těm datům. Samozřejmě je pak taky možnost, že firmy/lidi nezveřejní nějaké rozumné API, ale to v zásadě není rozdíl oproti třeba desktop aplikacím a od toho je tu freesoftwarové hnutí...
3.10.2019 14:58
xkucf03 | skóre: 49
| blog: xkucf03
Pro mě je důležitým rozdílem těsnost provázání. Klasické RPC si představuju tak, že ta klientská aplikace přímo zná jména metod v tom serverovém softwaru, parametry atd.
Jestli je to název metody nebo URL, je přece jedno – v každém případě potřebuješ mít nějaký jednoznačný klíč, který identifikuje ten bod na vzdáleném serveru, se kterým budeš komunikovat. Může to být URL odvozené z názvů adresářů či skriptů, může to být URL odvozené z názvu třídy/metody nebo z anotace, nebo může být všechno na jednom URL a klíčem bude třeba HTTP hlavička nebo nějaká hlavička či pole uvnitř formátu, který tím protokolem přenášíš (nemusí to jet ani přes HTTP).
Tohle je jen technický detail. Navíc na tom serveru máš typicky víc vrstev a jedna dělá to vnější rozhraní a pak většinou volá nějaké metody/funkce vrstev pod sebou. U nejjednodušších aplikací to může být všechno v té jedné vrstvě, ale tohle jsou fakt nepodstatné detaily.
taky to má víceméně instantní odezvu, resp. ne instantní, ale vázanou na to volání...
To je ale obecný princip volání typu požadavek-odpověď tzn. synchronní komunikace. Pak můžeš mít samozřejmě i asynchronní posílání zpráv. Nebo odpověď poslat hned po přijetí požadavku a zpracovávat ho až na pozadí asynchronně…
IMO ta pointa toho REST-like rozhrání je volnější provázanost a větší nezávislost těch komponent.
Volná vazba je mýtus. Resp. spousta lidí si ji vykládá špatně. Pokud se spolu dva systémy mají spojit, tak na sebe ta rozhraní musí pasovat. Toho se nejlépe dosáhne tím, že se kód na obou stranách generuje z nějakého jednoho strojově čitelného předpisu (SSOT). A i když to budeš dělat ručně, tak na sebe ta rozhraní musí pasovat včetně názvů polí, metod, koncových bodů… nespojí se to nějak zázračně samo. Volná vazba fakt není to, že nezdokumentuješ rozhraní a jen předhodíš uživatelům pár příkladů. (i když si to tak podstatná část lidí od webu představuje)
Plus také ten více FP-like model, kde místo volání metody a přijmutí výsledku vložíš nějaký data do nějaký trubky a výsledek se dostaví třeba někdy jindy v jiný trubce v rámci normálního datově-transformačního flow tý aplikace.
To už ale nesouvisí s tím rozhraním (RPC vs. REST), to už je otázka toho, odkud ta data přicházejí a kam je dál posíláš. Skrze to RPC klidně můžeš mít zpřístupněnou vzdálenou funkci, kterou voláš v rámci své funkcionální aplikace. Nebo můžeš volat REST rozhraní z aplikace, která vůbec funkcionální není.
Text článku a taky interface pro navigaci tvého webu a pro posílání komentářů. Ta data toho článku od toho UI té aplikace spolehlivě neoddělim (obecně).
Bohužel musím pracovat s tím, co je k dispozici (když chci, aby si to někdo jiný mohl přečíst). Neříkám, že je to dokonalé, ale pořád je lepší mít dokument, ke kterému je přibalená „aplikace“ pro posílání komentářů (kterou můžeš ignorovat a vykreslit si jen ten nespustitelný dokument) než mít nějakou SPA aplikaci, kde je všechno spustitelný kód a část z něj vykresluje obsah dokumentu a část ty ostatní věci – to mi přijde výrazně horší.
Jak jsem psal, líbilo by se mi, kdyby šlo nastylovat obecné XML – v něm by mohla být čistá data, klidně v nějakém existujícím formátu (jako když jsem tu ukazoval, jak nastylovat ten konfigurák a zobrazit si ho v prohlížeči). Jenže to by webu nesměli škodit lidi, kteří jsou posedlí nesnášenlivostí ke XML.
Taky by byla možnost v tom XHTML nechat jen obsah článku a ty věci kolem jako navigaci nebo komentáře generovat JavaScriptem. Jenže to by znamenalo zhoršení pro lidi, kteří nechtějí spouštět JavaScripty, a vlastně k tomu není pádný důvod – proč vyžadovat nějaký spustitelný kód, když ty odkazy nebo formulář můžou být obyčejné deklarativní XHTML elementy?
Nicméně spíš tam dodělám PDF výstup, což chci už dlouho, případně EPUB. To bude v rámci současných možností to nejlepší. Tzn. možnost si celý článek uložit k sobě na disk do jednoho souboru včetně obrázků a možná i příloh.
Jestli je to název metody nebo URL, je přece jedno – v každém případě potřebuješ mít nějaký jednoznačný klíč, který identifikuje ten bod na vzdáleném serveru, se kterým budeš komunikovat.Je podle tebe třeba spooling druh RPC? Podle mě ne. A REST API je (resp. měl by být) podle mě spíše spooling než RPC.
To je ale obecný princip volání typu požadavek-odpověď tzn. synchronní komunikace. Pak můžeš mít samozřejmě i asynchronní posílání zpráv. Nebo odpověď poslat hned po přijetí požadavku a zpracovávat ho až na pozadí asynchronně…Nebo odpověď vůbec nepovažuješ za "odpověď" (protože neděláš RPC), ale za obecná vstupní data, která se zpracovávají nezávisle na tom, jestli jsi "zavolal metodu" nebo jestli se někde změnil nějaký stav nebo něco. Já si myslim, že si nerozumíme na nějaké dost fundamentální úrovni, což je dané tím, že ty vidíš většinu věcí zkrz Java-like OOP model a nic jiného. A já asi nejsem ochoten a hlavně ani schopen předat v téhle diskusi někomu principy FP. (Navíc sám nemám FP zvládnuté zdaleka tak, jak bych rád.)
Volná vazba je mýtus. Resp. spousta lidí si ji vykládá špatně. Pokud se spolu dva systémy mají spojit, tak na sebe ta rozhraní musí pasovat.Volnost/těsnost té vazby je otázka množství asumpcí/invariantů, které musí ty strany dodržovat. Takový Vaadin určitě z tohoto pohledu vytváří o dost těsnější vazbu a, neznám ho sice, ale pravděpodobně znemožní nezávisle měnit technologii backendu a frontendu. Zajímavé je, že když se bavíme třeba o databázích, tak naopak prosazuješ volnější vazbu a aby třeba bylo možné vyměnit DBMS. A tady prosazuješ opačný přístup. Mně přitom dává mnohem větší smysl to mít obráceně, resp. minimálně by zaměnitelnost DBMS neměla mít větší prioritu než zaměnitelnost frontendu. To samé psaní desktop software - tam taky IIRC prosazuješ např. oddělení enginu a GUI.
než mít nějakou SPA aplikaci, kde je všechno spustitelný kód a část z něj vykresluje obsah dokumentu a část ty ostatní věci – to mi přijde výrazně horší.Kdybys k tomu měl REST-like API, které by zpřístupnilo jen ta data, tak to naopak bude výrazně lepší, protože pak je úplně jedno, jestli tam máš SPA nebo před-generované XHTML nebo cokoliv, protože tím se v té chvíli vůbec nemusim zabývat. Dokonce bys mohl třeba tu XHTML vyměnit za SPA a pak zase zpátky a mě jako uživatele toho REST API by to nijak neovlivnilo. Mohl bych si z toho generovat HTML nebo PDF nebo Tex nebo cokoliv bych chtěl... A na tohle je "moderní web" IMO orientován lépe, i když samozřejmě to nedělá dokonale a má jiné problémy. Pozn.: Tím nechci vyjádřit, že po tobě chci, abys to udělal. To určitě nemusíš a dost možná by to stejně byla zbytečná práce - u blogu nejspíš stačí např. ta PDFka. Zmiňuju to jen jako ilustraci.
6.10.2019 16:36
xkucf03 | skóre: 49
| blog: xkucf03
Je podle tebe třeba spooling druh RPC? Podle mě ne. A REST API je (resp. měl by být) podle mě spíše spooling než RPC.
Spooling? Jako že nasypeš požadavky do fronty a ony se pak někdy zpracují? To je fronta, posílání zpráv. Nesouvisí to s tím, zda přistupuješ ke vzdálenému zdroji (REST) nebo voláš vzdálenou proceduru/metodu/funkci (RPC). Jak REST, tak RPC jsou přirozeně synchronní forma komunikace – a v obou případech si tam můžeš předřadit nějakou frontu, do které posíláš požadavky, a pak když přicházejí odpovědi tak se volá nějaký tvůj kód (asynchronně). To už je věc té které aplikace, jak s tím bude pracovat – a ne věc toho rozhraní jako takového. Stejně tak si můžeš nějakou frontu udělat na straně serveru (a opět to nic nemění navenek na tom rozhraní).
Nebo odpověď vůbec nepovažuješ za "odpověď" (protože neděláš RPC), ale za obecná vstupní data, která se zpracovávají nezávisle na tom, jestli jsi "zavolal metodu" nebo jestli se někde změnil nějaký stav nebo něco.
Jasně, to můžeš, ale je to to asynchronní posílání zpráv. Nemá to nic společného ani s RPC, ani s RESTem.
Jestli uděláš GET /dokument/123 nebo getDokument(123) je v principu to samé – synchronní komunikace. V jednom případě se tomu dá říkat REST a v druhém případě je to RPC (obecnější princip). REST se vlastně dá považovat za speciální případ RPC, který tě tlačí k tomu, abys používal nějakou pevně danou množinu operací a určitou konvenci pro URL.
Já si myslim, že si nerozumíme na nějaké dost fundamentální úrovni, což je dané tím, že ty vidíš většinu věcí zkrz Java-like OOP model a nic jiného.
Je úplně jedno, v čem je klient a server naprogramovaný – tady se bavíme o tom rozhraní. Obě strany pak mohou být klidně naprogramované v jiném jazyce, můžou používat i jiné paradigma, ale to je jedno – od toho abstrahuješ a jen voláš to rozhraní, které je nějak definované.
Volnost/těsnost té vazby je otázka množství asumpcí/invariantů, které musí ty strany dodržovat.
Část těch předpokladů vychází z logiky řešené úlohy – např. chceš získat dokument, tak skrze to rozhraní musíš poslat jeho ID. Pak je část přepokldaů, která vychází z toho, že komunikuješ s počítačem a ne člověkem – takže to ID musí být v nějakém předem dohodnutém formátu (např. bez mezer a čárek, jen číslice) a v předem domluveném poli (např. idDokumentu) a musíš ho poslat na nějaké předem domluvené místo (např. URL, název metody/procedury/funkce). Zatímco kdybys komunikoval s člověkem, tak bys řekl: „chci dokument číslo 123“ – místo abys řekl: „dej mi dokument s ID 123“ – ta věta by vypadala pokaždé trochu jinak a třeba by ses zeptal i nesprávného člověka, ale stejně byste si rozuměli.
V případě počítače je ale potřeba dodržet nějaký protokol. To je ale pořád ještě volná vazba. Těsná vazba resp. příliš těsná vazba podle mého začíná ve chvíli, kdy je to moc křehké a začneš do toho zatahovat přepoklady, které nejsou nutné a nejsou ani nikde dobře zdokumentované. Např. když je potřeba obě části kompilovat stejnou verzí kompilátoru (ale nikdo vlastně neví proč) nebo když musíš mít na obou stranách dokonce nějaký jeden konkrétní software nebo knihovnu (a opět nikdo nedokáže rozumně vysvětlit proč).
Spousta lidí oprávněně nesnáší (příliš) těsnou vazbu. Nicméně řešením není zahodit dokumentaci a specifikace a dát na web jen nějaké příklady, ze kterých si to ostatní budou opisovat a odhadovat, jak se to rozhraní má používat. Řešením je právě dobrá dokumentace – kompletní specifikace, ve které máš vše potřebné, a která je ideálně ve strojově čitelném tvaru. Na základě toho je pak kdokoli schopný implementovat klientskou nebo serverovou stranu a bude to spolu fungovat.
Takový Vaadin určitě z tohoto pohledu vytváří o dost těsnější vazbu a, neznám ho sice, ale pravděpodobně znemožní nezávisle měnit technologii backendu a frontendu.
Vtip je v tom, že to není API, není to veřejné rozhraní. Framework tohoto typu ti umožňuje zapomenout starý způsob uvažování nad webem (kde to máš pořád rozdělené na klienta a server) a dívat se na to celé jako na jednu aplikaci. Prostě píšeš třeba účetní aplikaci nebo rezervační systém a neřešíš, co běží na které straně (pokud to explicitně řešit nechceš). Je to jako kdybys psal desktopovou aplikaci v nějakém frameworku – a tam taky většinou neřešíš, jestli se něco děje v procesu tvé aplikace nebo zda se to děje v procesu X serveru nebo Waylandu nebo nečeho jiného (nebo se to dokonce akceleruje na GPU). Soustředíš se na svůj byznys a od technických detailů abstrahuješ. Mimochodem pro Qt i GTK máš možnost aplikaci zpřístupnit přes web (což jsi v případě psaní té aplikace ani nemusel tušit, že to jde – a ono to jde).
Pokud tam má být nějaké veřejné API, tak vedle toho Vaadinu uděláš třeba SOAP nebo REST webové služby nebo GraphQL. A aby to bylo příčetné, tak k tomu dáš strojově čitelný popis rozhraní, aby se na to ostatní mohli dobře napojit.
Zajímavé je, že když se bavíme třeba o databázích, tak naopak prosazuješ volnější vazbu a aby třeba bylo možné vyměnit DBMS. A tady prosazuješ opačný přístup.
Troufám si říct, že většina lidí, kteří „dělají REST rozhraní“ není schopná je rozumně navrhnout, dobře zdokumentovat a garantovat, že se tato rozhraní budou do budoucna vyvíjet zpětně kompatibilním způsobem. Pro většinu lidí je to prostě jen způsob, jak dostat data ze serveru do prohlížeče, nějaké nutné zlo – a ve skutečnosti žádné (veřejné a stabilní) rozhraní dělat nechtějí.
V takovém případě klidně mohli použít ten framework typu Vaadin a ušetřit si tím spoustu práce a problémů.
Pokud někdo veřejné stabilní rozhraní dělat chce, tak ať si k tomu nastuduje nějakou teorii1, a pak poskytne strojově čitelnou specifikaci toho rozhraní. Z ní si ostatní ideálně vygenerují potřebný kód pro svoje prostředí a mají to bez práce. A nebo se z toho vygeneruje lidsky čitelná dokumentace, podle které si to rozhraní napíše ručně ten, kdo nechce nebo nemůže používat generátory. Každopádně v té specifikaci ale bude mít vše potřebné a bude to volná vazba bez nějakých neopodstatněných a hlavně nezdokumentovaných předpokladů (které je těžké splnit a v důsledku kterých jsou ta propojení mezi systémy příliš křehká).
Třeba v enterprise Javě nebo Springu je taková klasika třívrstvá architektura – máš tam datovou vrstvu, pak obchodní logiku a pak prezentační vrstvu. Když chceš vyměnit DBMS, tak vyměníš tu datovou vrstvu (nebo ji někdy právě stačí jen naparametrizovat) a když chceš vyměnit UI, tak změníš zase tu prezentační vrstvu. Ale ten základ (ve kterém bys typicky měl mít investováno nejvíc práce) je v té prostřední vrstvě, kterou si necháváš.
Kreslit tam nějakou tlustou dělící čáru mezi HTTP serverem a WWW prohlížečem je v mnoha případech nadbytečné. Pro spoustu lidí je to jen zvyk, historická zátěž, protože to tak vždycky dělali, protože měli v týmu někoho, kdo psal PHP na serveru a pak někoho jiného, kdo psal nějaké JavaScripty pro prohlížeč.
Určité reálné opodstatnění tam samozřejmě taky je (ta serverová část běží na tvém počítači, kterému věříš, zatímco ta klientská na cizím, kterému nevěříš). Ale tohle lze řešit genericky nějakým tím frameworkem, který to ohlídá.
Pokud se tedy ptáš na změnu UI, tak tady můžeš vyměnit tu prezentační vrstvu – můžeš třeba přecházet mezi tím Vaadinem a nějakým šablonovým UI postaveným na JSP, Thymeleafu případně JSF… zatímco ta střední vrstva s tou byznys logikou ti zůstává, na tu se sahat nemusí. Stejně tak ti zůstane API (a tím myslím skutečné API s dobrou specifikací, ne nějaké mimochodem-jakože-api, které jsi vytvořil, protože si potřeboval nějak propojit HTTP klienta a server, ale ve skutečnosti jsi ani žádné API moc dělat nechtěl).
Případně jsem někdy pracoval na systému, který ty vrstvy měl takhle: datová – obchodní – veřejné stabilní API – prezentační. Kde ta prezentační byla napsaná taky v Javě (ve frameworku podobném Vaadinu) a pokud běžela na stejném serveru ve stejném procesu, tak byla schopná se napojit přímo na tu obchodní a volat její metody (tzn. odpadla ta serializace a deserializace). Vtip takového uspořádání je v tom, že máš garantované, že když jde něco udělat v GUI, půjde to udělat i přes API. Takže máš jistotu, že se na nic nezapomnělo.
To samé psaní desktop software - tam taky IIRC prosazuješ např. oddělení enginu a GUI.
Ano. Ale viz výše – prostě jen nemám potřebu kreslit tu hranici mezi vrstvami tam, kde ji diktuje HTTP protokol. Tu hranici mezi prezentační a obchodní vrstvou si můžu udělat jinde – a často to tam dává větší smysl.
Kdybys k tomu měl REST-like API, které by zpřístupnilo jen ta data, tak to naopak bude výrazně lepší,
Lepší by to bylo jen za předpokladu, že bych navrhl a specifikoval veřejné stabilní API a někdo ho uměl používat. Je to poměrně dost práce a je to velký závazek pro autora (mne) udržovat to API do budoucna kompatibilní. Přínosy jsou poměrně malé a nejisté. Proto jsem raději použil nějaké již existující API – kterým je formát XHTML pro deklarativní (neprocedurální/neimperativní) popis hypertextových dokumentů – místo abych vymýšlel vlastní. Není to dokonalé, ale v rámci možností je to nejlepší volba.
A na tohle je "moderní web" IMO orientován lépe
Pokud ti nevadí, že se to API může kdykoli rozbít a nikdo ti negarantuje jeho stabilitu (protože si to píše jen jako interní rozhraní pro sebe)…
Naopak to XHTML má aspoň pevně definovanou množinu povolených elementů. Takže můžeš napsat např. generický převodník do TeXu, PDF atd. Není to dokonalé a vstupuje do toho ještě CSS, ale pořád je to řádově lepší než nějaké proprietární nezdokumentované JSON REST API.
Např. když si na stránku aplikuješ tiskové CSS styly, tak to dává relativně dobré výsledky. Nebo ve Firefoxu můžeš zapnout režim „zobrazení čtečky“, který z toho deklarativního dokumentu vykřeše relativně dobrý výsledek.
[1] ono to „dělat API“ fakt nespočívá jen v obsluze nějakého nástroje; mimochodem, doporučuji knihu Practical API Design – není to primárně o webu, ale to není podstatné – důležitější je ten způsob myšlení a schopnost si představit, jaké všechny problémy a situace můžou nastat a co se může v průběhu evoluce rozhraní rozbít… a jak se tomu dá čelit – tohle je dobré si přečíst bez ohledu na to, zda děláš API na webu, v Céčku, Javě nebo čemkoli jiném
Jako že nasypeš požadavky do fronty a ony se pak někdy zpracují? To je fronta, posílání zpráv. Nesouvisí to s tím, zda přistupuješ ke vzdálenému zdroji (REST) nebo voláš vzdálenou proceduru/metodu/funkci (RPC). Jak REST, tak RPC jsou přirozeně synchronní forma komunikace – a v obou případech si tam můžeš předřadit nějakou frontu, do které posíláš požadavky, a pak když přicházejí odpovědi tak se volá nějaký tvůj kód (asynchronně).Dejme tomu, že budu chtít třeba odesílat objednávku. Rozhraní s volnější vazbou bych viděl třeba tak, že bude nějaký endpoint na odeslání dat, kam klientská aplikace (webová, telefonní, atd. ... nebo třeba jen
curl z příkazový řádky) pošle data objednávky. Jestli to bude na tom serveru znamenat vytvoření souboru na disku nebo uložení dat do DBMS nebo třeba jen do in-memory DB odkud si to vyzvedne něco dalšího, příp. jestli to bude zpracovávat ten samý SW co servíruje stav aplikace nebo jiný, to už neřešim. Z pohledu klientské aplikace to je prostě upload dat, jako kdybys nahrál soubor v příslušném formátu na příslušné místo. Ať už by se ta data zpracovala jakkoli, tak v momentě, kdy dojde k nějakému vyhodnocení (přijetí apod.), se změní stav dat o objednávce, který aplikace zobrazuje, a aplikace si je pak načte v rámci svého běžného životního cyklu z příslušného endpointu nebo endpointů. Ani vlastně nemusí moc vědět, že data, která zobrazuje, se změnila nějak specificky právě v reakci na ten předchozí upload dat.
S dostatečnou fantazií na to určitě můžeš nějak napasovat RPC. Otázka je, jestli to má smysl. IMO nemá, mj. třeba z důvodů popisovaných v tom povídání od Fakezoobu. Opravdu mi přijde spíš smysluplnější se na to dívat jako na výměnu a transformace dat, koneckonců ty 'příkazy' jsou omezné právě proto, aby byly víceméně analogické práci s daty, jakoby se "soubory". REST API je často podobné jakémusi vzdálenému filesystému, kde "složky" a "soubory" mají trochu víc strukturovaná data. Případně si tam můžeš i představit něco jako rouru podobně...
Je úplně jedno, v čem je klient a server naprogramovaný – tady se bavíme o tom rozhraní. Obě strany pak mohou být klidně naprogramované v jiném jazyce, můžou používat i jiné paradigma, ale to je jedno – od toho abstrahuješ a jen voláš to rozhraní, které je nějak definované.No, ne no. Jak říkám, nerozumíme si na fundamentální úrovni. Rozhraní není nikdy abstraktní, nikdy není oproštěné od implementačních detailů toho, co je za tím, včetně programovacího jazyka a uvažování toho, kdo to rozhraní vytvořil...
Řešením je právě dobrá dokumentaceTak dobrá dokumentace je fajn věc, na tom se shodneme zcela bez ohledu na REST, RPC nebo cokoli...
Naopak to XHTML má aspoň pevně definovanou množinu povolených elementů. Takže můžeš napsat např. generický převodník do TeXu, PDF atd. Není to dokonalé a vstupuje do toho ještě CSS, ale pořád je to řádově lepší než nějaké proprietární nezdokumentované JSON REST API.IMO je to v podstatě to samý. To XHTML taky není dokumentované a žádné záruky zpětné kompatibility taky nevidim. Může se jakkoli změnit včetně komplet změny struktury a/nebo změny stupně konformity s různými standardy. Běžné XHTML elementy mi nijak extra nepomůžou, protože třeba <p> je použito pro obsah v článku i jinde v UI blogu... Krom toho, REST API neznamená, že musíš nutně servírovat data v JSONu. V případě blogu by v zásadě dávalo smysl i to XML, XHTML nebo třeba TeX nebo Markdown nebo něco takovýho... V JSONu by mohl být servírován třeba jen seznam zápisků...
7.10.2019 15:58
xkucf03 | skóre: 49
| blog: xkucf03
Dejme tomu, že budu chtít třeba odesílat objednávku. Rozhraní s volnější vazbou bych viděl třeba tak, že bude nějaký endpoint na odeslání dat, kam klientská aplikace (webová, telefonní, atd. ... nebo třeba jen curl z příkazový řádky) pošle data objednávky. Jestli to bude na tom serveru znamenat vytvoření souboru na disku nebo uložení dat do DBMS nebo třeba jen do in-memory DB odkud si to vyzvedne něco dalšího, příp. jestli to bude zpracovávat ten samý SW co servíruje stav aplikace nebo jiný, to už neřešim.
Já pořád moc nechápu, v čem by měl spočívat spor. Když pošlu data objednávky jako POST /objednávky/ tak dostanu zpátky jen potvrzení, že data přišla na server a asi ID založeného záznamu. Což je ale v principu to samé, jako když zavolám RPC int založObjednávku(Objednávka o) throws ExceptionXY – taky dostanu jen potvrzení, že data dorazila (absence výjimky1) a ID záznamu.
Tzn. jak REST, tak RPC se chovají synchronně. Něco jiného by byla ta fronta zpráv, která je asynchronní a kde bych žádné potvrzení o přijetí ani dostat nemusel nebo by mohlo být jen technické (ve smyslu: data sice přišla, ale neznamená to, že jsou v pořádku a že se založil záznam). V tom RPC to jde udělat taky – prostě tam jen nebude návratová hodnota. V případě RESTu by to mohlo fungovat, ale tam je zvykem to ID založeného záznamu vracet (a když to z toho REST rozhraní jen nacpu do fronty, tak v tu chvíli žádné ID záznamu nemám, ale na HTTP požadavek potřebuji nějak odpovědět).
Z pohledu klientské aplikace to je prostě upload dat, jako kdybys nahrál soubor v příslušném formátu na příslušné místo. … koneckonců ty 'příkazy' jsou omezné právě proto, aby byly víceméně analogické práci s daty, jakoby se "soubory". REST API je často podobné jakémusi vzdálenému filesystému, kde "složky" a "soubory" mají trochu víc strukturovaná data.
Tahle analogie u RESTu dost kulhá už od samého začátku. Když kopíruji soubor do nějakého adresáře, tak už předem znám celou budoucí cestu k tomu souboru a platí tam předpoklad, že jakmile nahrávání dokončím, jsem schopný si ho z této předem známé cesty zase stáhnout a dostanu přesně ten samý soubor. Kdežto u RESTu typicky potřebuješ, aby ty „cesty“ (ID) generoval a hlídal server, takže klient nahrává data na jinou adresu, než odkud si je později bude moci stáhnout. Případně tam dojde k nějakým dalším transformacím, a pak si stahuješ něco úplně jiného, než co jsi tam nahrál…
Tím tedy nechci říct, že je REST k ničemu, jen má určité vady asi jako cokoli. Tam kde se skutečně pracuje (z logiky věci) se zdroji, dává jeho použití smysl a je to elegantnější než to řešit pomocí procedur.2
v momentě, kdy dojde k nějakému vyhodnocení (přijetí apod.), se změní stav dat o objednávce, který aplikace zobrazuje, a aplikace si je pak načte v rámci svého běžného životního cyklu
Jak si je načte? Web je v tomhle hrozný mrzák resp. je na něm vidět to, že se technologie určená pro přenos hypertextových dokumentů zneužila pro tvorbu aplikací, a chybí tam ta obousměrná komunikace. Resp. chyběla do doby zavedení WebSocketů. Před tím se to všelijak hackovalo a musel ses na stav periodicky dotazovat nebo nechat dlouho otevřený HTTP požadavek a doufat, že ti mezi tím nespadne spojení. Díky těm WebSocketům se dají posílat zprávy obousměrně a už ta architektura aplikace může vypadat úplně jinak (ale to už nemá s RESTem nebo RPC nic společného). Mimochodem Vaadin právě umožňuje fungovat i přes WebSockety – ani si toho nevšimneš, funguje to navenek stejně, ale všechna data v obou směrech se valí přes jeden WS kanál. Pak tam hezky a snadno implementuješ třeba posílání událostí ze serveru do GUI – např. se tam aktualizují hodnoty v grafu nebo v nějakém formuláři. A z programátorského hlediska je to podobné, jako kdybys psal desktopovou aplikaci třeba v Javě nebo v Qt. Prostě tam emituješ nějaké události a ony se dostanou do GUI a nemusíš řešit, že někde mezi tím je nějaká síť.
Ani vlastně nemusí moc vědět, že data, která zobrazuje, se změnila nějak specificky právě v reakci na ten předchozí upload dat.
To nemusí ani u RPC, ani u RESTu, ani u posílání zpráv.
S dostatečnou fantazií na to určitě můžeš nějak napasovat RPC.
Podle mého na to ani moc fantazie nepotřebuješ, přijde mi to intuitivní. Běžně potkávám nebo vytvářím procedury/metody/funkce, které pracují tímhle způsobem – dostanou nějaká data a jen potvrdí jejich přijetí a případně vrátí nějaký identifikátor, se kterým můžeš dále pracovat (třeba se zeptat, jak operace dopadla, nebo ji stornovat atd.).
Případně si tam můžeš i představit něco jako rouru podobně...
Jasně, ale to může i s RPC – ta procedura je prostě jen vstupní bod, skrze který posílám data do nějaké roury. Ostatně když budeš třeba v C posílat datagramy do soketu, tak to děláš taky pomocí nějaké funkce – resp. v podstatě všechno je tam funkce, která má nějaký požadavek (vstupní parametry) a odpověď (návratovou hodnotu). Dokonce i asynchronní resp. neblokující funkce vypadají stejně, akorát třeba mají návratovou hodnotu prázdnou nebo jsou definované tak, že když požadavek nejde momentálně vyřídit, tak vrátí prázdnou/chybovou odpověď hned a ty víš, že je máš zavolat znovu.
Rozhraní není nikdy abstraktní, nikdy není oproštěné od implementačních detailů toho, co je za tím, včetně programovacího jazyka a uvažování toho, kdo to rozhraní vytvořil...
Viz třeba to céčkovské API – přes něj taky můžeš propojit dva programy napsané úplně jiným stylem, podle jiného paradigmatu, v jiných jazycích. Všechno je to vzájemně převoditelné. Nad RPC nebo RESTem můžeš implementovat vkládání zpráv do fronty a jejich následné (asyncrhronní) vyzvedávání. A nad WebSockety nebo nějakou frontou můžeš zase implementovat synchronní volání typu požadavek-odpověď tzn. nějaké ty metody, procedury či funkce, prostě si tam jenom na straně klienta přidáš nějakou synchronizaci a počkáš si, než přijde z fronty odpověď. Mimochodem, znáš Enterprise Integration Patterns? Těch způsobu interakce je mnohem víc a v zásadě jdou všechny implementovat pomocí libovolné technologie.
Tak dobrá dokumentace je fajn věc, na tom se shodneme zcela bez ohledu na REST, RPC nebo cokoli...
Tak aspoň něco :-)
IMO je to v podstatě to samý. To XHTML taky není dokumentované a žádné záruky zpětné kompatibility taky nevidim. Může se jakkoli změnit včetně komplet změny struktury a/nebo změny stupně konformity s různými standardy. Běžné XHTML elementy mi nijak extra nepomůžou, protože třeba <p> je použito pro obsah v článku i jinde v UI blogu...
Když si článek na svém blogu zobrazím ve Firefoxu v tom režimu „zobrazení čtečky“, tak to Firefox trefí docela hezky – a to jsem ten XHTML kód nijak pro Firefox neladil.
[1] nebo tam nemusí být výjimka, může to vracet záporné ID jako chybu atd. to už je jedno
[2] jiná otázka pak je, jaké k tomu existují nástroje a standardy, např. pro strojově čitelný popis těch rozhraní a generování kódu, ale tady REST už ten svůj deficit díky OpenAPI (Swaggeru) celkem napravil
Já pořád moc nechápu, v čem by měl spočívat spor.No v ničem, je to o úhlu pohledu. Můj názor (osobní, subjektivní) je, že dívat se na to jako na RPC (případně snažit se na to narvat násilím Javu) vede k návrhům podobným tomu, který kritizují v té přednášce linkované výše.
ale na HTTP požadavek potřebuji nějak odpovědětNepotřebuješ. Stačí 200 OK.
Tahle analogie u RESTu dost kulhá už od samého začátku. Když kopíruji soubor do nějakého adresáře, tak už předem znám celou budoucí cestu k tomu souboru a platí tam předpoklad, že jakmile nahrávání dokončím, jsem schopný si ho z této předem známé cesty zase stáhnout a dostanu přesně ten samý soubor.Analogie přece neznamená, že to je úplně to samé...
Viz třeba to céčkovské API – přes něj taky můžeš propojit dva programy napsané úplně jiným stylem, podle jiného paradigmatu, v jiných jazycích. Všechno je to vzájemně převoditelné.No, něco je převoditelné, ale koncepty mnoha jazyků navzájem převoditelné nejsou a v tom C API prostě zmizí. C API obecně narušuje invarianty většiny jazyků.
Mimochodem, znáš Enterprise Integration Patterns?Ok, tohle už je prostě trolling
Když si článek na svém blogu zobrazím ve Firefoxu v tom režimu „zobrazení čtečky“, tak to Firefox trefí docela hezky – a to jsem ten XHTML kód nijak pro Firefox neladil.No jo, ale je to heuristika ... a krom toho to je JS kód běžící u uživatele, jsem myslel, že to je Zlo?
Přitom tam kdesi v pozadí ty dobré myšlenky jsou: HTML (data) + CSS (formátování).Chybí definice UI/layoutu. To CSS nikdy nemělo a v podstatě na to nic pořádnýho neexistuje.
Než otěže vývoje webu převzalo uskupení WhatWG se svým odporem ke XML, tak nadějně vypadal standard XForms. Ale jinak souhlasím, že pokud chcete obecnou aplikaci, tak potřebujete turingovsky úplný jazyk, nikoliv deklarativní dokument. A na to je pár řádků imperativního javascriptu praktičtější, než onanie s XSLT2.
30.9.2019 20:23
xkucf03 | skóre: 49
| blog: xkucf03
tak nadějně vypadal standard XForms
Ano, XForms je škoda (že se pořádně nepoužívají).
Než otěže vývoje webu převzalo uskupení WhatWG se svým odporem ke XML
On se ten iracionální odpor ke XML projevuje např. i tak, že zavrhli jmenné prostory, ale reálně je potřebují, což ovšem odmítají přiznat a místo toho tam raději začali mastit prefix data- k atributům. Naprosto zvrácené. Totéž dělá Angular. Čisté a obecné řešení jsou XML jmenné prostory, které už dávno byly vynalezeny, stačilo je použít a nevynalézat hranaté kolo.
Další věc je, že rozlišují „párové“ a „nepárové“ značky místo toho, aby prostě pracovali se vším jako s elementy (které lze zapsat prázdné <element/>). Což má za následek to, že už nemůžeš mít obecně použitelný parser, ale musíš mít parser specifický pro HTML5, který ví, které značky jsou párové a nepárové. V XML je tohle krásně oddělené – můžeš mít generický parser, který nemusí vědět nic o tom formátu, který je nad tím XML postavený, a stejně ho umí rozparsovat.
On se ten iracionální odpor ke XML projevuje např. i tak, že zavrhli jmenné prostory, ale reálně je potřebují, což ovšem odmítají přiznat a místo toho tam raději začali mastit prefix data- k atributům. Naprosto zvrácené.Odpor ke XML IMO není iracionální, XML je prostě hnus. Ten nápad XML jako takovej asi v zásadě špatnej není, ale ta implementace hrozně saje. Kdyby někdo vzal XML a vyhodil z toho ty špatné části - tzn. skoro všechno kromě toho základního nápadu - tak bych to třeba i bral. Co bych potřeboval, aby to byl ten formát rozumně použitelnej:
--" v komentářích apod.Další věc je, že rozlišují „párové“ a „nepárové“ značky místo toho, aby prostě pracovali se vším jako s elementy (které lze zapsat prázdné <element/>).IIRC párové/nepárové tady jsou starší než XML a při tvorbě XML si prostě akorát celkem logicky řekli, že to přejímat nebudou. (Bohužel ale spoustu jiných věcí přejali.)
V XML je tohle krásně oddělené – můžeš mít generický parser, který nemusí vědět nic o tom formátu, který je nad tím XML postavený, a stejně ho umí rozparsovat.No, ne tak úplně. Viz tenhle blogpost - ilustruje tam, že musíš vědět, jestli element je citlivý na whitespace nebo ne.
6.10.2019 18:41
xkucf03 | skóre: 49
| blog: xkucf03
Kdyby někdo vzal XML a vyhodil z toho ty špatné části
S vyhozením uživatelsky definovaných entit bych souhlasil. Jmenné prostory jsou naopak jedna z nejdůležitějších kladných vlastností.
Apostrofy a uvozovky taky dávají smysl – při parsování je to minimální práce navíc, ale zásadně to usnadňuje zápis (např. když vkládáš XML jako text někam do uvozovek, tak můžeš uvnitř použít apostrofy a naopak a nemusíš to escapovat).
Datové typy máš v XSD.
Běžné escapování se dělá přes &, kdežto CDATA jsou trochu něco jiného – jakou bys navrhoval syntaxi místo toho?
Ad "--": v jiných jazycích si zase musíš hlídat "*/". Ono tohle obecně moc nemá řešení – něčím ten komentář nebo CDATA končí, tak to logicky nemůžeš psát dovnitř.
V zásadě se mi jako vhodný kandidát jeví např. TeX-like syntaxe (pokud se pročistí od vestigialit TeXu). Např. něco takového udělali v LiliPondu, ačkoli tam zas mají spoustu domain specific věcí. Minimálně je to ale přijěmnější na editace a čtení člověkem.
Návrhů je spousta, včetně různých Wiki a Markdown syntaxí, Texy, Jira, BBCode atd. Problém je jednak v tom, že jich je spousta, takže musíš pořád v hlavě přepínat mezi různými syntaxemi a neexistují pro to moc nástroje. A jednak v tom, že tyhle formáty nejsou rozšiřitelné a nejsou jednoznačné – dříve či později narazíš na nějakou kolizi, něco, co nejde napsat, nebo se chová nelogicky.
K té rozšiřitelnosti: v XML můžeš do dokumentu snadno přidávat další metadata nebo různé anotace. Viz třeba to Sane software manifesto – na vstupu je XML obsahující i různá metadata, a pak se z toho pomocí jednoduché XSLT šablony generuje XHTML (případně pak i PDF nebo TXT). Viz
hg clone https://hg.globalcode.info/sane-software/sane-software-manifesto/
A je snadné do toho něco doplnit, označit si nějak části textu, přidat kategorie atd. Jak bys tohle řešil v nějakém tom „jednodušším“ formátu? (maximálně tak v tom TeXu, ale ten už se pak blíží tomu XML, akorát tam máš jiné závorky).
Nezneužívat formát pro serializaci dat, konfiguraci a podobně, jako se to děje s XML. Formát na dokumenty má být na dokumenty.
XML umožňuje popsat libovolnou stromovou strukturu. A konfigurace je stromová struktura. Krásně to na sebe pasuje. Navíc u XML máš schéma, validace, transformace… což se právě u té konfigurace hodí – díky tomu máš třeba napovídání v editoru, kontrolu syntaxe nebo vizualizaci (už jsem tu někde odkazoval tu šablonu, která zobrazí konfigurák jako XHTML).
Ano, někdy stačí konfigurace typu klíč=hodnota (třeba javovské .properties soubory) nebo někdy si vystačíš se skupina/klíč=hodnota (tzn. např. INI soubory). Ale to je oboje jen podmnožina stromových struktur. Jsou to omezené formáty, u kterých si často nejdřív myslíš, že ti budou stačit, a pak narazíš (a pak se tam různě prasí a ad-hoc se vymýšlí, jak pomocí nich zapsat nějakou stromovou strukturu nebo řešit jiné věci, které XML umí v základu). A chybí pro ně nástroje – některé programy třeba umí zkontrolovat svůj konfigurák typu klíč=hodnota a vypsat ti chyby, ale to musel někdo naprogramovat speciálně pro ten jeden daný program, není to použitelné nikde jinde. Napovídání v editorech snad nikde pro tyto formáty nefunguje atd.
XML umožňuje popsat libovolnou stromovou strukturu.To umí celá řada formátů... XML mi přijde na konfiguraci nevhodné především proto, že nemá datové typy (mimo stringu) a má výše zmíněné problémy s whitespace* a kódováním. *) Např. to, že XML nody
<foo attr="hello world">
<foo attr=" hello
world">
xml:space jsou úplně k ničemu, protože implementace to často ignorují a mají svoje vlastní nastavení. Třeba XHTML zachovává whitespace vždy, protože jinak by nefungovalo třeba <pre> a ekvivalentní CSS nastavení pro jiné elementy. Na druhou stranu ale nad tím pak v mnoha (většině) případů provádí transformace jako kdyby ho ignorovalo, a to jinak pro atributy a jinak pro textový obsah. Jakým způsobem bude whitespace interpretovat konfigurační deserializátor? V podstatě se můžu jenom dohadovat.
Třeba JSON sice nemá komentáře a má debilní pravidla pro oddělovací čárky, ale alespoň když tam vidím string, tak přsně vím, jakým způsobem si ho aplikace přečte. Samozřejmě aplikace s tím stringem může dále udělat cokoli, nicméně když nastane problém s whitespace, tak alespoň vím, že ten problém není ve formátu.
Navíc u XML máš schéma, validace, transformace… což se právě u té konfigurace hodí – díky tomu máš třeba napovídání v editoru, kontrolu syntaxe nebo vizualizaci (už jsem tu někde odkazoval tu šablonu, která zobrazí konfigurák jako XHTML).To je teoreticky dobrý, ale reálně nevim o někom, kdo by to používal (kromě tebe). Smysl exportu konfigurace do XHTML se přiznánm nevidim**. U té validace v zásadě vidím pointu a bylo by to třeba i dobré, kdyby XML byl dobře implementovaný formát s dobrým toolingem. Osobně to teď obvykle prostě řešim tím, že deserializátor konfigurace je vygenerovaný z typů použitých v programu (např. serde), což řeší i validaci.
Ano, někdy stačí konfigurace typu klíč=hodnota (třeba javovské .properties soubory) nebo někdy si vystačíš se skupina/klíč=hodnota (tzn. např. INI soubory). Ale to je oboje jen podmnožina stromových struktur. Jsou to omezené formáty, u kterých si často nejdřív myslíš, že ti budou stačit, a pak narazíš (a pak se tam různě prasí a ad-hoc se vymýšlí, jak pomocí nich zapsat nějakou stromovou strukturu nebo řešit jiné věci, které XML umí v základu).Třeba TOML umí stromovou strukturu. Formáty jako INI nebo podobně bych nepoužíval, protože nejsou dobře definované (nejasné kódování, escapování atd.). **) Nicméně pokud to někdo potřebuje, tady je minimalistický příklad, jak přetransformovat JSON do XHTML pythonem:
#!/usr/bin/env python3
import sys, json, jinja2
jinja2.Template(u"""<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="application/xhtml+xml; charset=utf-8" http-equiv="Content-Type" /><title>Konfigurace</title>
</head>
<body>
<ul>
<li>foo: {{foo}}</li>
<li>bar: {{bar}}</li>
</ul>
</body>
</html>
""").stream(**json.load(sys.stdin)).dump(sys.stdout)
{
"foo": 3,
"bar": "Hello, World!"
}
těžko hovořit o materiální svobodě libovolného uživatele.ne a ne, uplne kazdy libovolný uzivatel na svete ma slobodu a stale bude mat aj v buducnosti pouzivat a vylepsovat povodne KHTML o ktorom sa bavime. BSD licence zarucuje slobodu programu teraz aj v budcnosti. Neviem, preco furt do diskusie zatahujes uplne ine produkty, uplne inych spolocnosti?!
23.9.2019 19:09
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
To bych někdy chtěl vidět. GNU/Windows.
23.9.2019 22:01
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
24.9.2019 11:20
cezz | skóre: 24
| blog: dm6
GNU/WindowsInak povedane WSL? Tam mas GNU system beziaci nad Windows jadrom.
24.9.2019 12:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
25.9.2019 16:57
cezz | skóre: 24
| blog: dm6
25.9.2019 20:48
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
23.9.2019 20:33
pushkin | skóre: 43
| blog: FluxBlog
23.9.2019 21:02
Fluttershy, yay! | skóre: 93
| blog:
To nebylo myšleno jako "uzavření" ve smyslu "closed source", ale ve smyslu "zavřít dveře", tj. odstranění/zneškodnění toho backdooru.
Možnost, že někdo nechá backdoor v projektu, u kterého zveřejní zdrojáky, není vúbec hypotetická, jak ukazuje příklad Interbase, kde i po otevření zdrojáků zůstal backdoor jak vrata od stodoly. Spekuluje se ale, že to nejspíš nebyl úmyslný backdoor, ale spíš zkratka, kterou tam kdysi nechal nějaký líný vývojář a o které ani Borland nevěděl.
24.9.2019 01:20
xkucf03 | skóre: 49
| blog: xkucf03
GPL by umožnila udělat fork, takže by z toho šlo jednak vyházet ten spyware, DRM a další škodlivé vlastnosti. A jednak by to šlo použít jako dokumentaci nebo z toho vzít části kódu a vylepšit Wine. Případně udělat nějakou kontejnerovou emulační vrstvu pro běh aplikací původně psaných pro Windows. Takže by lidi konečně přestali remcat, že jim „nejde Photoshop“ nebo na co si to stěžují.
Tiskni
Sdílej:
