abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 09:11 | Zajímavý článek

Mozilla.cz informuje o vylepšování vlastních about: stránek Firefoxu, konkrétně o odstraňování volání funkce eval() z těchto stránek. Tyto stránky mají přístup k interním součástem Firefoxu, ale protože jsou napsané v HTML a JavaScriptu, mohou být cílem podobných útoků jako webové stránky zobrazované v prohlížeči (např. vložení cizího kódu nebo obsahu), jen s potenciálně závažnějším dopadem. Pokud by se někomu skutečně povedlo kód do

… více »
Ladislav Hagara | Komentářů: 3
dnes 08:55 | Zajímavý projekt

Uživatel GitHubu joeycastillo představil The Open Book Project, jehož cílem je vytvořit open-source čtečku elektronických knih. Projekt se zatím nachází v rané fázi vývoje, už nyní ale obsahuje použitelný návrh hardware prototypu „Feather Wing“, jehož cílem má být ověření konceptu na 4,2palcovém displeji. Tento koncept je postaven na kitu Adafruit Feather M4 Express, který ovládá hlavní desku s displeji a tlačítky. Po úspěšném ověření

… více »
Bystroushaak | Komentářů: 17
dnes 05:00 | Nová verze

Byla vydána verze 5.0.0 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata (Wikipedie). Přehled novinek v oficiálním oznámení a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Zajímavý projekt

Byly zveřejněny schémata, firmware a instrukce pro sestavení trackballu Ploopy. Ten používá Arduino, senzor PMW3360 a 1,75palcovou kouli. Zdrojové soubory jsou šířeny pod open-hardware licencí CERN a GNU GPLv3. Tvar je inspirovaný klasickým trackballem Microsoft Trackball Explorer, jehož výroba byla ukončena kolem roku 2005 bez náhrady; projekt Ploopy se k tomu ale z právních důvodů nehlásí. Již vyrobené díly je možno objednat za 200 kanadských dolarů. Další podrobnosti v příspěvcích uživatele crop_octagon na Redditu.

Fluttershy, yay! | Komentářů: 17
včera 20:22 | Nová verze

Vyšlo desktopové prostředí KDE Plasma 5.17. Novinkou je např. „noční režim“ (pro X11, nejen Wayland), skrytí upozornění při prezentacích (když je připojena obrazovka se stejným obrazem), lepší podpora HiDPI, optimalizace využití zdrojů a mnoho drobných zlepšení a oprav.

Fluttershy, yay! | Komentářů: 1
včera 12:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 169. brněnský sraz, který proběhne v pátek 18. října od 19:00 v restauraci Racek (Jungmanova 5). Před srazem proběhne v 18:00 komentovaná prohlídka nových prostor hackerspacu base48 (přístup je z Mojmírova náměstí).

Ladislav Hagara | Komentářů: 8
včera 05:55 | Bezpečnostní upozornění

V příkazu sudo byla nalezena a ve verzi 1.8.28 byla již opravena bezpečnostní chyba CVE-2019-14287. V souboru /etc/sudoers lze nastavit, aby daný uživatel mohl konkrétní příkaz spouštět s právy libovolného uživatele (ALL) nebo libovolného uživatele kromě uživatele root (ALL, !root). Spustí-li tento uživatel daný příkaz se sudo s volbou -u#-1 nebo -u#4294967295, tj. pod uživatelem -1 nebo 4294967295, nebude vyžadována autentizace a příkaz se spustí pod právy roota.

Ladislav Hagara | Komentářů: 1
včera 01:33 | Nová verze

Po více než roce a čtvrt od vydání verze 3.7.0 byla vydána nová verze 3.8.0 programovacího jazyka Python. Přehled novinek v aktualizované dokumentaci. Podrobný přehled změn v Changelogu.

Ladislav Hagara | Komentářů: 15
14.10. 16:11 | IT novinky

Ke zhlédnutí na Invidious a YouTube je videozáznam rozborky a sborky mobilního telefonu Librem 5.

Ladislav Hagara | Komentářů: 52
14.10. 13:33 | Komunita

Richard Stallman, zakladatel hnutí svobodného softwaru, se dnes v e-mailové konferenci guix-devel vyjádřil, že svobodný software je apolitický, resp. jedinou přípustnou politikou je politika svobodného softwaru. Reagoval na některé návrhy, že by se do svobodného softwaru měl zabudovat feminismus nebo jiný -ismus. Říká, že témata jako komunismus nebo sexuální orientace jsou „off-topic“. Je v pořádku mít politické názory, ale lidé

… více »
xkucf03 | Komentářů: 105
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (19%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 404 hlasů
 Komentářů: 22, poslední 23.9. 08:36
Rozcestník

www.AutoDoc.Cz

Richard Stallman o své přednášce v Microsoftu

Richard Stallman se v příspěvku na svém blogu vrací ke své přednášce konané 4. září přímo v Microsoftu. V závěru zmiňuje, že viceprezidentovi Microsoftu doporučil uvolnit zdrojové kódy Windows pod licencí GNU GPL.

23.9. 15:33 | Ladislav Hagara | Zajímavý článek


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

23.9. 16:53 Wallace
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Nechápu co Stallman tolik baziruje na GPL. Vždyť to neni úplně svobodná licence.
23.9. 17:39 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
A která je svobodnější než GPL?
Vykook avatar 23.9. 18:01 Vykook | skóre: 23 | blog: Tomas
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
BSD, WTFPL (...)
Nejde nám o dobro druhých. Nejde nám o bohatství. Jde o čisté opojení mocí.
Fluttershy, yay! avatar 23.9. 18:19 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Jak mi to pomůže jako uživateli? Aha, nijak.

Aspoň AGPL…

Ačkoliv, dost možná je na místě zamyslet se nad tím, co jsou zač kteří uživatelé.
23.9. 18:46 odin
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
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?
Fluttershy, yay! avatar 23.9. 18:49 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Hele, gestapák odin, jak charakteristické.
23.9. 19:10 yxcyxc
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
o nic horší než anarchokomunista
Fluttershy, yay! avatar 24.9. 23:45 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Jedno je v jádru založeno na genocidě, druhé nikoliv.

Myslíš, že genocida je dobrá?
24.9. 12:14 odin
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Pořád jsi neodpověděl na otázku.
23.9. 19:16 Wallace
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Mas prilis jednoduchy pohled na "uzivatele". To kdyz nepotrebuji spoustet software ale pouzivat jeho zdrojaky tak nejsem uzivatelem toho software nebo co ? GPL je presne o tom, garantuje jakou-takou svobodu pro BFU ale ne pro pokrocile uzivatele (vyvojare). GPL obsahuje sluvko "must" nejmene 14x takze je buhvico ale urcite ne svobodna. Doufam, ze to uz koncence chapes a prestanes znasilnovat pojem "svoboda" stejne jako Stallman.
23.9. 20:51 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
GPL svobodu zajišťuje i do budoucna. BSD se svobodou nemá moc společného, pokud tím nemyslíš svobodu korporací SW ukrást.

GPL je mnohem lepší licence než BSD.
23.9. 21:08 Wallace
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Ale ja vubec netvrdim, ze GPL je spatna licence! Mne jenom stve, ze se oznacuje za SVOBODNOU licenci. To slovo "svoboda" tam vubec nepasuje, protoze ta licence spoustu veci narizuje. Takze to neni o tom, ktera licence je dobra ci spatna a co resi, je to o znasilneni vyznamu SVOBODA. Kapisto ?
23.9. 21:14 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Ano, narizuje drzet svobodu. Proto je svobodná. Zatímco BSD to nenařizuje a umožňuje změnit SW na uzavřenou nesvobodnou komerční sračku.

Svobodné země mají také zákony, zatímco v anarchii typu Somálska si moc svobody neužiješ.
23.9. 21:28 Wallace
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Tak vidis jaky paskvil to znasilnovani definice "svobody" GPL licenci nadelalo. Ted jsou lidi schopni rikat hlouposti na jine licence jako "nesvobodna"! Takovehle prekrucovani sme uz tady meli za bolsevika a vedlo to do dost hluboke pici z ktere se zrejme jeste mnoho z vas nevzpamatovalo dodnes. Svoboda je svoboda, tu nemuzes narizovat ani si ji prvlastnovat tam kde neni. A to je GPL. Nema se svobodou moc spolecneho i kdyz se o to snazi. Osobne si myslim, ze se jen pohrali s anglofonnim dvojvyznamem sluvka free, protoze o bezplatny software slo tehdy predevsim. Pak si na tom dvojsmylu Stallman postavil politickou agendu a siri lzi o tom, ze v GPL je svoboda, coz samozrejme nebyla a neni. Sam jednou uzna, ze je cas na v4 kde se vypusti to sluvko "must", protoze svobodu nelze zakazat ci prikazat, ta bud je nebo neni. A v oblasti SW je jenom jedina svoboda - delej si s kodem co chces.
Fluttershy, yay! avatar 23.9. 21:44 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu

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.

23.9. 22:10 MZ
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Demokracie (řeckého typu) byla úplně v pohodě než za lid začali považovat i ženy. Od doby co mají ženy volební právo vám demokracii naruší kde jaký populista. Cesta zpátky asi není, takže jediný pokrok v demokracii vidím v tom, že pro změnu zakážeme volit muže a pro jistotu zakážeme volit i mužům. A pak se to snad vrátí do správných koleji...
⧠ A = 0 avatar 24.9. 07:04 ⧠ A = 0 | skóre: 9 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Demokracie je sama o sobě populistická (z definice).
Nevolte zmrdy.
24.9. 09:53 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Nechápeš význam slova populismus. Je to něco úplně jiného než demokracie. V jistém smyslu vlastně opak.
⧠ A = 0 avatar 24.9. 10:02 ⧠ A = 0 | skóre: 9 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Sám jej nechápeš. Opak to rozhodně není.
Nevolte zmrdy.
24.9. 11:12 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
demokracie je vlada lidu,

populismus je zpusob jak s lidem manipulovat a vladnout mu - casto nastup k totalite

⧠ A = 0 avatar 24.9. 14:34 ⧠ A = 0 | skóre: 9 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Pravděpodobně si pleteš populismus s demagogií.
Nevolte zmrdy.
24.9. 15:40 _
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Ne, nepletu si nic.
24.9. 20:08 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
On ty kecy VKML bere nekdo vazne? A jeste je siri? :-D
--- vpsFree.cz --- Virtuální servery svobodně
⧠ A = 0 avatar 25.9. 07:30 ⧠ A = 0 | skóre: 9 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Nevím, VKML nesleduji, nicméně tipl bych si, že pokud něco takového říká, bude vycházet z premisy, že populismus je zlo.

Já na populismu jako takovém nic špatného nevidím, problém je falešný populismus lidí (oligarchů) jako AB, kteří jej používají jako fíkový list pro své vlastní obohacení.
Nevolte zmrdy.
Ovoce avatar 26.9. 00:21 Ovoce | skóre: 14 | blog: Vyplizlo_ze_zivota
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
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

ROFL :D
23.9. 21:59 Omaha
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Ano, ten pojdem svobodný software je poněkud nešťastný. To se už několikrát řešilo, ale už to asi nikdo měnit nebude protože se to vžilo. GPL jde v zásadě o to aby odvozený produkt byl pořád open source s GPL licencí. Tuhle kontinuitu otevřeného kódu nazvali free software. Zdá-li to je šťastný název nebo ne, už asi nevyřešíme, vžil se a musíme s ním žít.
xkucf03 avatar 24.9. 01:15 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Svobodné licence a copyleft
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.9. 22:00 OldFrog {Ondra Nemecek} | skóre: 31 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Každý ať si vybere svoji podobu svobody. A podle toho zvolí i licenci.
-- OldFrog
xkucf03 avatar 24.9. 01:13 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Svobodné licence a copyleft
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.9. 10:59 Wallace
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
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.
Fluttershy, yay! avatar 24.9. 11:03 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Zrušením otroctví dostala na frak svoboda obchodovat s otroky.
24.9. 11:22 Petr
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Myslím, že to nechápeš. GPL zaručuje trvalé svobody, proto je svobodná. BSD toto neumí, svobodu neumí bránit. Proto bych ji ani svobodná neříkal, rozhodně je svobodná méně než GPL.
24.9. 11:37 Wallace
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Nechapes ty. Porad resis co ktera licence dela nebo nedela. O to tady nejde. Jde o nespravne pouziti, ci spise zneuziti slova "svoboda", o semantiku pouziti slova "svoboda". Licence ktera 14x neco narizuje nemuze by svobodna i kdyby narizovala svobodu :D
24.9. 11:39 _
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
To je naprostý blábol. Zajeď si do Somálska a medituj tam o svobodě. Za rok se vrať a medituj nad bláboly, co tu píšeš.
24.9. 11:49 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Dělá z nás ústava, která zaručuje občanské svobody nesvobodnou společnost?
24.9. 13:34 Wallace
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Jeste jednou, ja neresim vyznam a uplatneni GPL licence. Ale to, ze neco narizuje. To z ni pak dela nesvobodnou licenci. GPL by byla svobodna, kdyby misto "musis" pouzila "bylo by skvele kdybys". Proste neprikazovat, ale nechat to rozhodnuti svobodne na tobe.
Fluttershy, yay! avatar 24.9. 13:41 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
xkucf03 avatar 24.9. 14:01 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
25.9. 06:54 Wallace
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Mne se jen nelibi pouziti slova "svobodny software" v spojeni s GPL, ktera svobodna neni. To je vse. GPL ma tady misto a pro mnohe projekty je prinosem. Jen ji proste nevolejte svobodna licence. To tu budu vytykat pod kazdou zpravickou a clankem pokud nejaky autor napise ze "svobodny software" a ja kouknu na zdrojaky a vida GPL.
25.9. 07:57 _
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Tak to budeš mít v životě hodně práce, ale každý může se svým životem naložit jak chce.
24.9. 16:34 BoneFlute
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Jestli tě chápu dobře, pak jediná opravdu svobodná licence je taková, která říká, že "tady máš kód, můžeš si s ním dělat co chceš". V extrémím případě "tady máš kód, můžeš si s ním dělat co chceš, a pokud ho nemůžeš stáhnout, tak ti ho osobně přinesu na flešce".

Zdá se mi, že zbytečně bazíruješ na slově "muset". Dotaženo do extrému licence, která říká, že si potencionální zájemce může kód stáhnout, tak taky říká, že musíš si ho stáhnout odtud. Což je absurdní. Vždycky něco musíš.

Trochu mi to přípomíná příběh jedné paní, která se strašně moc chtěla naučit hrát tenis. Ale nedokázala překousnout, že by musela chodit na trénink a poslouchat trenéra a muset dělat to, co jí učí.
25.9. 00:34 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
I BSD licence některé věci nařizuje, výslovně říká, že něco musíte. To z ní tedy rovněž dle vaší popletené definice dělá nesvobodnou licenci.

Toto je základní nepochopení významu slova svoboda na úrovni první třídy základní školy. Pochopení významu tohoto slova patří k základnímu vzdělání stejně jako čtení a psaní. Svoboda opravdu neznamená, že nic nemusíte a všechno můžete. V každé svobodné společnosti platí spousta závazných nařízení.
24.9. 12:24 V.
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Platnost licence končí tam, kde začíná něco jiného.
Proč by to nemohlo dávat smysl?
Množiny patří do základního vzdělání, že?
24.9. 21:20 Tom K | skóre: 20
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Nic si z toho nedělej. Jen se ti pletou pojmy "svoboda" a "anarchie". To se dětem stává často, ale obvykle to časem přejde.
echo -n "u48" | sha1sum | head -c3; echo
24.9. 22:45 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Pokud vím, i anarchisté chápou nutnost nějakých zákonů. Jen vidí jinak jejich zdroj. To o čem mluví on je čistý chaos.
xkucf03 avatar 24.9. 23:31 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Anarchie je neudržitelná
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Fluttershy, yay! avatar 24.9. 23:36 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Anarchisté zpochybňují hierarchické instituce jako stát (a „copyright“ je monopol garantovaný právě státem, potažmo nadstátními organizacemi, které však vystupují primárně některých států a korporací). To neznamená, že anarchistická společnost se žádným způsobem nereguluje.

Nezaměňovat anarchisty s ancaps (aka korporátní neofeudalismus).
25.9. 09:35 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Však tady (doufám) nejsme v rozporu?
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ů.
25.9. 14:15 Milan Uhrák | skóre: 28 | blog: milan_at_ABC
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Svoboda, hochu, je poznaná nutnost ... ne anarchie
24.9. 15:01 Erlang Senior Developer
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
To je blbost, BSD tiez zarucuju trvalu svobodu produktu aj v buducnosti. Ak moj program pouzije nejaka komercna firma a zmeni mu licenciu, nema to absolutne ziadny vplyv na moj povodny program, ten stale ostava slobodny.
Fluttershy, yay! avatar 24.9. 15:16 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
V praxi to vypadá tak, že KHTML už jaksi není relevantní a WebKitu existuje asi tucet různých forků v různých stádiích rozkladu.
25.9. 11:54 Erlang Senior Developer
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Ale to KHTML z ktore bolo forknute je stale pod tou istou licenciou a kazdy kto chce ho moze slobodne pouzivat a vylepsovat ho, ak chce. Mna ako uzivatela KHTML nezaujima ze Apple a potom Google si urobili fork...to uz su ine produkty.
Fluttershy, yay! avatar 25.9. 12:12 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Pokud je jeho účelem prezentovat weby, v řadě praktických příkladů to poněkud narazí.
26.9. 08:31 Erlang Senior Developer
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Ale ved ty ako uzivatel KHTML ho mozes vylepsovat ak potrebujes. BSD licencia ti to umoznuje. BSD licencia zarucuje programu trvalu slobodu.
Fluttershy, yay! avatar 26.9. 10:34 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
Ano, to v praxi vidíme, jak se od KHTML oddělil WebKit a dnes je z něj katedrála budovaná pár velkými entitami, z nichž některé rovněž významně určují, jak vypadají vstupní data, tj. weby.

Právě těmto entitám – nebo lolbertariánskému poustevníkovi v atomizované společnosti – to třeba vyhovuje, leč těžko hovořit o materiální svobodě libovolného uživatele.
xkucf03 avatar 26.9. 10:52 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše složitost webu, standardy

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Fluttershy, yay! avatar 26.9. 11:02 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
To je technická masturbace, která neřeší příčiny, a sice to, že majoritní platformy pro sdílení obsahu jsou vůbec vyvíjeny za účelem poskytování co nejvíce [cílené] reklamy, což určuje, kam směřují zdroje.
xkucf03 avatar 26.9. 11:08 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy

Tak na ty platformy nechoď a vytvoř něco lepšího…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Fluttershy, yay! avatar 26.9. 11:13 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
Co taky čekat od lolbertariánského poustevníka v atomizované společnosti.

Systémová změna se dělá systémově. Jako třeba že antimonopolní úřad oddělí reklamní divizi od platformy. Což je typické řešení tržního liberalismu.
xkucf03 avatar 26.9. 11:48 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Fluttershy, yay! avatar 26.9. 11:54 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Františka poznamenal neoliberalismus
Společnost tak obvykle funguje, pokud sis doposud nevšiml.
26.9. 12:42 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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ý je
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é...
xkucf03 avatar 26.9. 13:20 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
26.9. 15:52 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.
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.
No, to ale IMO platí o většině technologií, včetně třeba operačních systémů, textových editorů atd atd...
xkucf03 avatar 28.9. 10:44 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
29.9. 16:36 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
Tak ono už se to do jistý míry nahrazuje. JS frameworky většinou integragují přímo s DOM API prohlížeče. Směrem k programátorovy to pak řeší různě. Ironicky, např. hodně používané JSX je opět zase XML, které se ale transformuje do JS objektů. Asi to udělali z důvodu familiérnosti. Ale na XML to v podstatě nezávisí a je to víceméně jen o zápisu ze strany programátora. Existují alternativy (1, 2). Jiný frameworky mají taky nějaký svoje reprezentace, třeba Elm ...
xkucf03 avatar 29.9. 21:53 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
30.9. 16:21 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.
xkucf03 avatar 30.9. 17:38 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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í frontendbackend 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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
xkucf03 avatar 30.9. 17:39 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
Příloha:
Příloha.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
30.9. 18:44 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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říklad
Funkcioná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 fungovalo
Jak 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...)

xkucf03 avatar 30.9. 19:56 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.10. 00:39 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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 application/x-www-form-urlencoded a multipart/formdata . To je IMO pěknej humus.
xkucf03 avatar 1.10. 10:00 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.10. 14:26 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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í...
xkucf03 avatar 3.10. 14:58 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
3.10. 18:52 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.
xkucf03 avatar 6.10. 16:36 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
7.10. 01:32 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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á dokumentace
Tak 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ů...
xkucf03 avatar 7.10. 15:58 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
7.10. 23:46 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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ět
Nepotř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 :-D
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?
30.9. 20:07 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.

xkucf03 avatar 30.9. 20:23 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.10. 01:26 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: složitost webu, standardy
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:
  • Formát by měl mít natvrdo UTF-8. Povolit libovolné kódování a pak dovnitř v tom kódování napsat, co to je za kódování, je střevní myšlenka.
  • Vyřešit ecaping, pokudmožno rozumným způsobem, ne něco, co si zjevně vycucal z konečníku sám Satan (mluvím pochopitelně o CDATA). CDATA vrazit do srdce kůl, pokropit svěcenou vodou a zahrabat někam hodně hluboko za současného zaříkání kněží nejméně 3 náboženství.
  • Sjednotit escaping pro atributy a obsah nodů.
  • Když už, tak používat jen jedny uvozovky. Nejlépe ale přehodnotit syntaxi atributů celkově.
  • Vyházet entity (escaping by měl stačit)
  • Jasně stanovit whitespace rules
  • Měl by se to dát rozumně ručně zapisovat i bez specializovaného editoru, který doplňuje uzavírací tagy, hlídá překřížené tagy, "--" v komentářích apod.
  • Přidat lehce nějaké datové typy, zejména relevantní pro dokumenty, tzn. např. datum/čas (tohle má třeba TOML). (Tohle ale může bohužel vést na zneužití formátu pro data.)
  • Namespaces buď zjednodušit/zpoužitelnit, nebo vyhodit.
  • 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.
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. Dělat něco takovýho v XML by IMO bylo hrozný utrpení pro všechny kromě skalních XML-BDSM nadšenců...
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.
xkucf03 avatar 6.10. 18:41 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: složitost webu, standardy
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).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
xkucf03 avatar 7.10. 09:51 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše XML pro konfiguraci
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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
7.10. 15:07 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: XML pro konfiguraci
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">
a
<foo attr="    hello
world">
jsou isomorfní (v závislosti na nastavení parseru), mi přijde vyloženě úchylný, mj. např. z toho důvodu, že se uvozovky chovají neintuitivně a zcela v rozporu s použitím uvozovek prakticky kdekoli jinde. A věci jako 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)

Na standardní vstup má přijít něco jako { "foo": 3, "bar": "Hello, World!" }
7.10. 15:11 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: XML pro konfiguraci
Pozn.: Na jednom nejmenovaném projektu, na kterém se účastním, je INI formát znásilněn tak hrozným způsobem, že bych tam jako náhradu bral i to XML, i když bych z toho nebyl třeba kdovíjak odvázanej. Tzn. je to relativní.
26.9. 12:25 Erlang Senior Developer
Rozbalit Rozbalit vše Re: Svobodné licence a copyleft
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. 21:57 OldFrog {Ondra Nemecek} | skóre: 31 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
+1
-- OldFrog
23.9. 17:30 Andrej | skóre: 9
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
pekny html kod, aj ked jeden krat mu to pretieklo cez 80 znakov na riadok
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
Grunt avatar 23.9. 19:09 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Teď když je Richard víceméně nezaměstnaný by ho mohli v Micosoftu zaměstnat, že? Třeba na pozici v otázce svobodného softwaru. :-D To bych někdy chtěl vidět. GNU/Windows.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
23.9. 20:27 Lael Ophir
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Budeš se divit ale Microsoft má jenom na githubu kolem 2700 opensource projektů. Samozřejmě vesměs pod pořádnými licencemi jako MIT nebo Apache. Žádný GNU GPL kočkopes.
Grunt avatar 23.9. 22:01 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Budeš se divit
Nebudu. Vždyť Microsoft GitHub koupil. Ale prostě tomu důvěřuju asi tolik jak tomu kočko-psovi.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
cezz avatar 24.9. 11:20 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
GNU/Windows
Inak povedane WSL? Tam mas GNU system beziaci nad Windows jadrom.
Computers are not intelligent. They only think they are.
Grunt avatar 24.9. 12:14 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Tak na to aby to mohlo být označované jako součást projektu GNU by musel být celý systém pod licencí GPL (a ještě nějak požehnán z řad FSF), vč. jádra. Nebo ne?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
24.9. 13:39 BillG
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
https://github.com/microsoft/WSL2-Linux-Kernel/blob/master/COPYING
cezz avatar 25.9. 16:57 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Linux je sucastou BSD?

Tiez tu mame GNU/kFreeBSD, kFreeBSD pokial viem nie je pod GPL licenciou.
Computers are not intelligent. They only think they are.
Grunt avatar 25.9. 20:48 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Však to tak není operační systém GNU a nebo jeho součást, ne?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
pushkin avatar 23.9. 20:33 pushkin | skóre: 42 | blog: FluxBlog
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Nejsem si jist, že by GPL Windows vylepšilo. Špatný software zůstane špatným software, ať je pod jakoukoliv licencí...
"...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
Fluttershy, yay! avatar 23.9. 21:02 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Možností forku by se řešily praktické problémy jako uzavření univerzálního backdooru či vendor lock-inu.
23.9. 21:41 Wat
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Wat ? Jaký význam by mělo ten backdoor nechat uzavřený a zbytek kódu mít otevřený ?
24.9. 07:48 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu

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.

xkucf03 avatar 24.9. 01:20 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu

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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Ovoce avatar 24.9. 20:25 Ovoce | skóre: 14 | blog: Vyplizlo_ze_zivota
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Spíš přidal spyware do instalátoru, a pak to cpát lidem na pochybnejch stránkách a vydělávat na tom, jak to vykukové dělaj s LibreOffice nebo VLC.

A forky by byly super, aspoň by to začalo fungovat stejně dobře jako Linuxový distra :)
23.9. 22:19 /dev/urandom
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
to by bol koniec Linuxu...
23.9. 22:32 m.
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Co mi vime, treba by Linuxu nejaka konkurence prospela.
24.9. 10:34 Marek
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
Nebo Windows. Kdovi jak by se podaril prechod na SystemD.
24.9. 06:47 -nd-
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
to by byl pruser az na pudu, kdyby se zjistilo kolik tam je jeste chyb :D
26.9. 07:36 Milan Uhrák | skóre: 28 | blog: milan_at_ABC
Rozbalit Rozbalit vše Re: Richard Stallman o své přednášce v Microsoftu
No, pokud se týče plánů Windows, tak jsem někde viděl rozhovor s tím jejich novým šéfem ( ceo tomu říkaj ) a ten vyslovoval takové divné věci, jako že by byl rád kdyby jádro windows obsahovalo linux kernel, že by bylo možné v commandline (cmd) přímo psát linux nebo shell ( command.com) příkazy a podobné blouznění ....

A co se týče pojmu "svobodný softvare" ... myslím že někteří diskutující tady mají buď horečku nebo trpí nacistickými sklony. Tato dvě slova, pokud tím míníme GNU GPL totiž patří k sobě, a nejsou každé zvlášť. Nelze se nimrat se slovem svobodný a software pak k tomu přilepit. Je to jako "svobodná žena". Taky tím není myšleno, že jeji život nespoutávají nějaká pravidla.

Svobodný software je tu od toho , aby poskytoval svobodu ostatním ve věci jeho užívání, studia, přispívání, atd. kdyby něměl pojistku, která nutí využivatele tohoto svobodného software výsledky své práce (odvozený software) na základě práce někoho jiného (poskytnuté svobodně) udržovat neustále jako svobodný, byl by to jen potenciálně svobodný sw, a opět bychom mohli šťourat co by to vlastně znamenalo .... anarchii.

Snad jsem se vyjádřil dost nesrozumitelně...

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.