Commodore OS Vision (Wikipedie) byl vydán v nové verzi 3.0. Jedná se o linuxovou distribuci určenou pro fanoušky značky Commodore. Předinstalována je na počítačích Commodore 64x.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 208. brněnský sraz, který proběhne v pátek 25. dubna od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1.
Ve svém článku Getting Forked by Microsoft popisuje autor programu Spegel svoji nepříjemnou zkušenost s firmou Microsoft. Firma ho kontaktovala a zpočátku to vypadalo, že by mohlo jít o oboustranně prospěšnou spolupráci, autor tedy ochotně odpovídal na jejich otázky ohledně architektury programu a pomáhal jim ho zprovoznit. Následně komunikace ze strany Microsoftu utichla. Autor předpokládal, že zřejmě došlo ke změně priorit a firma
… více »Společnost Notion Labs stojící za softwarovou platformou pro spolupráci Notion (Wikipedia) oficiálně představila (YouTube) poštovního klienta Notion Mail. Aktuálně funguje pouze nad Gmailem.
Byla vydána nová verze 9.12 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Ubuntu 25.10 bude (𝕏) Questing Quokka (pátrající klokan quokka).
Ubisoft uvolnil zdrojové kódy softwaru Chroma pro simulaci barvosleposti pro vývojáře počítačových her. K dispozici jsou na GitHubu pod licencí Apache 2.0.
Defold (Wikipedie) je multiplatformní herní engine. Nejnovější verze je 1.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Licence vychází z licence Apache 2.0.
Správa služeb hlavního města Prahy se potýká s následky kyberútoku. Hackerská skupina začala zveřejňovat na internetu některé z ukradených materiálů a vyzvala organizaci k vyjednávání. Ta zatím podrobnosti k případu sdělovat nechce. Případem se zabývá policie i Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB).
Skupina zaměřená na koordinaci a shromažďování informací prospěšných projektu Multiplatformní přístup pro datové schránky.
| Založena: | 5. 10. 2009 |
| Členů: | 26 |
| Článků: | 0 |
| Wiki stránek: | 7 |
| Dotazů: | 22 |
| Akcí: | 0 |
| Čtenost: | 30 % |
| Skóre: | 19 |
Přepsal jsem návrh zadání do editovatelné formy na wiki stránku.
Navrhuji následující:
- Dáme diskuzi dva dny a potom se výsledky diskuze pokusím zanést na wiki stránku.
- Navrhuji abychom se následně minimálně zadavatelé (ABCLinuxu) a hlavní řešitelé potkali osobně a potvrdili si že tohle je to ono, co chceme vytvořit.
Prosím o maximálně konštruktivní připomínky níže do diskuze.
Řešení dotazu:
> Kdo je primarne cilova skupina
Dle dosavadní diskuze soudím (prosím o korekce) že cílovou skupinou je:
Pro velké firmy to bez archivace příliš význam mít nebude + pravděpodobně budou požadovat integraci na jejich stávající systémy typu: digitální archiv, systém evidence doporučené pošty z podatelny, atď ...
Co se týče rozsahu funkcí tak nevím, jestli je v první fáze nutné knihovnou podporovat níže uvedené rozhraní. Jinak myslím, že napojení na zbývající WS, jak je popsané v zadání je v rozumném rozsahu.
1.1 Správa schránky (definované pomocí db_manipulations.wsdl, dokument DataBox_ws.doc z dokumentace):
Nejdulezitejsi use case jsou precteni a odeslani datove zpravy, ostatni je SHOULD ci dokonce NICE. Knihovna toho muze umet vice nez GUI.
Vezmu to trochu více high level, ale také je to zadání. Projekt chci rozdělit na více fází, z nichž každý bude mít své řešitele. Každý se tak může zapojit dle svých schopností a možností. V první fázi by měla vzniknout knihovna poskytující funkce pro základní manipulaci se schránkou. Nemusí mít všechny funkce, stačí opravdu jen ty nejnutnější pro to, aby výsledné aplikace byly užitečné. Klidně se můžeme smířit s tím, že některé méně časté use case bude nutné dělat třeba přes webové rozhraní (typicky administrace, která je jednorázového charakteru). Důvod je jednoduchý. Malé cíle se lépe plní, velké cíle odrazují od samého počátku.
V této fázi je důležité navrhnout slušné API. Bude dobře, pokud vzniknou zároveň verze pro C/C++ a Java, které mají ekvivalentní rozhraní. Toto rozhraní by mělo být funkční a odzkoušeno (nejspíš na nějakém prototypu). Také by mělo mít automatické testy, ať máme aspoň nějakou představu o kvalitě. Až budeme mít tu fázi za sebou a splněn první cíl, vybereme si další cíl. Budeme zase o něco chytřejší a lépe se nám určí, co to má být. Zda původní návrh na rozšíření Thunderbirdu, samostatná aplikace, java aplikace, OOo funkce pro odeslání do datové schránky nebo něco jiného.
Souhlasíte se mnou? Pokud jo, pojďme tedy omezit seznam funkcí a stanovit si cíl pro první fázi. Příští týden budeme mít jednání o spolupráci s jednou známou organizací, která má podobný projekt a OSS Aliance nám přislíbila zveřejnění svých PHP kódů pro práci s DS své spisové služby. Za týden budeme tedy vědět více a určíme si termíny, protože jinak půjde o zbožné přání a ne úkol. Mezitím bude třeba najít programátory, kteří budou ochotni přiložit ruku k dílu a vytvořit požadovanou knihovnu.
Tento případ a řadu dalších může pomoci vyřešit navrhovaný způsob realizace. Knihovna, která bude umět komunikovat s ISDS a nad ní postavené další aplikace pro konkrétní způsoby použití.
Pokud bude knihovna splňovat naše představy, (multiplatformní, dobře zdokumentovaná, s otevřeným zdrojovým kódem, s kvalitním API, ...) postavit nad ní vámi navrhované řešení a optimalizovat ho pro vaše prostředí by mělo být řešitelné poměrně snadno.
Dovedl bych si představit i řadu vylepšení nád rámec principů POP3.
13.10.2009 15:00
Mintaka | skóre: 13
Důležité jsou klady a zápory takového řešení, co zohlednit, na co si dát pozor. Významné jsou i zkušenosti lidí, kteří už s danými technologiemi mají zkušenosti, například už plugin pro Thunderbird vyráběli nebo pracují jako admini v prostředí, kde se daná technologie intenzivně používá, a pod.
Takze je realne, aby jeden clovek mel v jednom TB profilu pristup k vice DS. Zajimava informace
Rozjet a dotáhnout rychle ke zdárnému konci fázi 1 je zásadní věc. Nejde jen o splnění úkolu, ale také o kvalitu, rychlost splnění, dokumentaci. Navrhoval bych stanovit odměnu alespoň C/C++ AŽ 15000 AŽ Java 10000. Bylo by také vhodné sepsat doporučení, jak by takový kvalitní kód měl vypadat.
Například:
Zase na druhou stranu, abychom příliš vysokými požadavky na kvalitu neodradili případné zájmce.
Vzal jsem to z opačné strany a mám nástřel implementace knihovny v C (libcurl, libxml2) a začínají na povrch vyplavávat problémy nebo alespoň otázky:
Autentizace klienta je přípustná čtyřmi různými způsoby, prakticky se jedná o dva (vzájemně se nevylučujícíc se) způsoby: HTTP basic a klientský SSL certifikát.
První způsob je jasný, jediná otázka je ohledně cachování hesla, protože SSL spojení se může kdykoliv rozpadnout a co pak? Vyhodit aplikaci chybu, ať poskytne znovu heslo, nebo si heslo při přihlášení schovat a potichu jej znovu použít (respektivě cookie, na který se autentizace deleguje)? S tím souvisí ochrana před odswapováním hesla. Máme mlock(3), ale knihovna pro HTTP si heslo kopíruje pro sebe. Tohle se dost blbě ošetřuje.
Autentizace certifikátem má z vyhlášky povinnost mít klíč schovaný nevydolovatlným způsobem v kryptografickém zařízení, které dle provozního řádu ISDS musí implementovat MS CryptoAPI nebo PKCS#11 prostřednictvím knihovny libp11(?). Ví někdo o kryptografickém zařízení, které v linuxu funguje, splňuje tyto podmínky (mimo jiné 2048b RSA a SHA-2) a dá se za rozumné peníze koupit? Bude tento způsob autentizace povinnou součástí zadání?
Další problém je s ověřováním digitálních podpisů obálek. Dle provozního řádu byl XMLSec opuštěn kvůli výpočetně drahé kanonizaci XML a místo toho se podepisuje konkrétní serializovaný bitový proud XML podstromu a podpis se ukládá do PKCS (#7 ?) struktury.
Z toho vyplývá, že záleží na fyzické struktuře XML a z HTTP těla SOAP odpovědi bude nutné patřičný XML dokument zpřístupnit vyšším vrstvám jako prostý řetězec. Opakovanou serializací by se mohla porušit fyzická struktura a podpis by neseděl. Nevíte jak je na tom libxml2? Jestli umí zachovat fyzickou strukturu i po deserializaci? Ve své knihovně zatím vracím rezebraný XML strom (přesněji řečeno seznam uzlů (xmlNodeList) z těla SOAP), takže možná bude nutné vracet i dokument jako blob (ať paměťová složitost roste).
Další problém je s licencí. Rád bych do knihovny zahrnul XML schémata, abych mohl příchozí a třeba i odchozí zprávy validovat. Na to bych rád do knihovny začlenil XSD soubory z provozního řádu. Jenže podle českého autorského zákona podléhají úplně normální licenci, kromě výjimky (úřední dílo), že dílo mohu rozmnožovat a šířit. Mám ale dojem, že už nemám právo jej pozměňovat. To by pak ale bylo v rozporu třeba s licencí LGPL, protože ta uživateli dává právo cokoliv měnit. Jaký je váš názor, bude nutné schémata přepsat, šířit samostatně nebo požádat o lepší licenci Českou poštu, nebo se mýlím?
Další problém nastane, až se knihovnu někdo pokusí použít z aplikace. Spousta grafických knihoven si uzurpuje proces pro sebe, některé mají problémy s vícevláknovými procesy. Knihovně by asi slušelo asynchronní rozhraní, aby aplikace mohla oznámit, že byl zahájen přenos zprávy, pak ukazovat indikátor postupu a uživateli dát kdykoliv možnost přenos přerušit. (Vezmete na vědomí, že velikost zprávy může být až 10 MB, což na 128kb/s uplinku ADSL telecomu představuje nezanedbatelnou dobu.) Bude zadání tedy požadovat asychnronní vláknově bezpečné rozhraní, nebo ne? Problém může být s vláknovou bezpečností, protože třeba libcurl může být slinkovaná proti kryprografickým knihovnám, které nejsou připraveny na vlákna.
Zdravím, jsem rád že se to již slyšitelně hýbe. Přeji hodně zdaru.
Některé otázky si zřejmě vyžádají diskuzi více lidí.
RE ods. 3: poskytne znovu heslo, nebo si heslo při přihlášení schovat a potichu jej znovu použít Tohle chování by moho být volitelně nastavitelné v konfiguračním souboru. Zatím pro pohodlnější ladění bych doporučoval volit pamatování hesla.
RE ods. 4: klíč schovaný nevydolovatlným způsobem v kryptografickém zařízení To tam fakt je.. hmm. V tom případě to všichni co nám porušují, nebo se pletu?
RE ods. 5. 6. : Jestli umí zachovat fyzickou strukturu i po deserializaci Ještě aby si člověk dělal vlastní xml parser ... tfuj, kdo poradí?
RE ods. 7. : o lepší licenci Českou poštu, nebo se mýlím Určitě začít tímto směrem, v podstatě z jejich role vyplývá skoro povinnost, pomáhat (nebo aspoň se snažit dělat že pomáhají). Na tuhle práci bych doporučil jednoho odvážného člověka jménem FrantaS Zkusím ho na ten problém upozornit.
RE ods. 8. : Bude zadání tedy požadovat asychnronní vláknově bezpečné rozhraní, nebo ne? Z mého skormného úhlu pohledu, pro první fázi vývoje je jádro aplikace a výběr knihoven na kterých to bude stát důležitější, než propracovaná funkcionalita přístupu k DS. Tudíž bych byl pro "asychnronní vláknově bezpečné rozhraní" + ošetření reakcí na základní systémové signály. Pokud by se tam vešla i nějaká propracovaná struktura pro mezivláknovou/procesovou komunikaci, tím lépe. Už tu byly i lidé s požadavky na serverové řešení, které by obsluhovalo více uživatelů.
RE ods. 4: klíč schovaný nevydolovatlným způsobem v kryptografickém zařízení To tam fakt je.. hmm. V tom případě to všichni co nám porušují, nebo se pletu?
Písmeno d) 1. odstavce § 2 194/2009 Sb.:
(1)Pro přihlašování do datové schránky lze použít elektronický prostředek, který je kryptografickým prostředkem
d) neumožňujícím přenos soukromého kryptografického klíče podle písmene a) z tohoto elektronického prostředku,
Jeden by řekl, že co není zakázáno, je dovoleno, a tudíž odstavec pouze vysvětluje, jak je možné činit, a nikoliv, že pouze tak činit je možné, ale asi se tím myslí, že je to jediný možný způsob.
Už tu byly i lidé s požadavky na serverové řešení, které by obsluhovalo více uživatelů.
To není problém, u mně nejprve aplikace zavolá isds_ctx_create(&context), která vrátí strukturu specifickou jedné relaci (tedy vše mezi jedním přihlášením a odhlášením z jedné schránky). Ostatním funkcím pak aplikace předává tuto strukturu (isds_login(context, …)).
To vypadá jako schůdné řešení.
Jak bude aplikace reagovat na další požadavek, který by přišel v průběhu obsluhy toho prvního?
Mohla by tam třeba fungovat interní fronta požadavků.
Nějaký parametr pro nastavení timeoutu na max délku vyřízení požadavku by se také šiknul. Případně i kolikrát se má pokusit navázat spojení a prodlevu mezi pokusy. (Ale to už jsou takové jemné fičůrky. Aby se pak člověk neutopil v detailech.)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
Další problém je s licencí. Rád bych do knihovny zahrnul XML schémata, abych mohl příchozí a třeba i odchozí zprávy validovat. Na to bych rád do knihovny začlenil XSD soubory z provozního řádu. Jenže podle českého autorského zákona podléhají úplně normální licenci, kromě výjimky (úřední dílo), že dílo mohu rozmnožovat a šířit. Mám ale dojem, že už nemám právo jej pozměňovat. To by pak ale bylo v rozporu třeba s licencí LGPL, protože ta uživateli dává právo cokoliv měnit. Jaký je váš názor, bude nutné schémata přepsat, šířit samostatně nebo požádat o lepší licenci Českou poštu, nebo se mýlím?
Asi budeme muset nechat petrovi_p trochu času, než se odtrhne od programování
Prozatím jsem si pročítal Předmět práva autorského, asi jde především o § 2 odst. 2, i když ten by mohl přebýt odst. 4. že bychom si udělali překlad jejich schématu do struktury validátoru a § 3 je odst. a) by na to šel snad taky použít.
Tak jsem se znovu díval do autorského zákona a § 3 říká:
Ochrana podle práva autorského se nevztahuje na
a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho listin, jakož i úřední návrh úředního díla a jiná přípravná úřední dokumentace, včetně úředního překladu takového díla, sněmovní a senátní publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany,
Měl jsem za to, že pozměňování není dovoleno, ale podle současného znění zřejmě ano.
Teď už jen zbývá uvěřit, že Provozní řád ISDS je veřejná listina, s čímž by neměl být problém. Je pod tím podepsán Ing. Pavel Tesař a jako vydavatel MV ČR, Sekce rozvoje a projektového řízení ICT v oblasti veřejné správy.
Takže se omlouvám, že jsem zbytečně strašil.
Na to bych rád do knihovny začlenil XSD soubory z provozního řádu. Jenže podle českého autorského zákona podléhají úplně normální licenci, kromě výjimky (úřední dílo), že dílo mohu rozmnožovat a šířit. Mám ale dojem, že už nemám právo jej pozměňovat.
V tom případě bych volil "každého" a do pravidel odměny zahrnout i časový faktor, případně posloupnost:
První řešení bude začínat na 100% + % bonusy za kvalitu odvozené ze základní částky.
Druhé řešení např 70% z první částky + % bonusy z 70% výchozí částky.
Případné třetí řešení 70% z částky pro druhé řešení ...
Určitě by se s tím dalo pohrát.
Já bych byl přísnější:
Řešení, které porota vybere jako nejlepší, získá celou částku, ostatní dostanou 50%. Kdo nesplní podmínky (viz výše), nedostane nic. Porota - já, ty a on se snad někdo další přihlásí.
V tomhle případě jde mnohem víc o něco jiného než o finanční odměnu. To je jen taková třešinka na dortu. Ale i taková zkažená třešinka může pokazit celkový dojem. Proto bych raději volil základní částku navyšovanou o bonusy za kvalitu provedení, než určil max částku a od ní odečítal za nedostatky. S časy bych byl též opatrný, protože se může vyskytnout řada překážek, za které autoři nemohou. Pokud budou každý dělat řešení cílené na jinou skupinu uživatelů, tak bych naopak doporučil výraznou spolupráci a sdílení kódu tam kde to je možné. Mohlo by například vzniknout jádro, na kterém budou spolupracovat a věci kolem už každý bude řešit jinak.
Co se finálního rozhodování týče, tak jsem navrhoval, že by mu mohly předcházet 2 ankety, veřejná, pro kohokoliv a soukromá, pro sponzory a lidi podílející se na projektu. Výsledky by nemusely být brány brány jako směrodatné, ale byly by zohledněny.
Ovšem jsou to jen představy. Nevidím do možností, které v téhle situaci umožňuje zákon. Hlavně to neopatrným nakládáním s odměnami autorům neznechutit.
Ještě mám jednu nejasnost. Toto psal pan Kočí z Trasku:
602FormFiller se nepouziva pro odeslani datove zprávy, ale pro odeslani prilohy k autorizovane konverzi. Duvod je, ze jsme nebyli schopni zjistit, jestli na Czechpointu existuje rozhrani, které by mohly volat aplikace 3.stran.
Jak se nás to dotýká?
"Autorizované konverzi?": Pod tím bych si představil, že tu přílohu Filler někam pošle, tam se s ní něco stane a upravená verze se pošle zpět. To zní dost tajemně. Jestli je tam nějaká taková bota tak na to take brzy narazíme. Takových překážek tam může být víc a těžko s teď nimi nějak snažit vyrovnat. Spíš bychom se měli snažit vytvořit takové podmínky, aby až na něco takového přímo narazíme, abychom věděli na koho se obrátit za které špagáty potáhnout a naopak kde zatlačit.
Určitě bude dobré udržovat kontakty se všemi, kteří tím mají něco společného, až budeme chtít něco užitečného prosadit, bude lepší, když nás bude víc.
Třeba žádost o vytvoření datové schránky, která se standardně vyplňuje ve Filleru, je možné zrovna tak odeslat přímo přes API ISDS. Jak jsem zkoumal formát formuláře, mám dojem, že používá úplně stejné SOAP rozhraní. Takže ten Filler je v podstatě jen jiný „webový prohlížeč“ k ISDS.
Přímo o konverzi informační web Czech POINTu tvrdí, že teoreticky není nutné používat „aplikaci“ Czech POINT @Office, ale že stačí, aby vlastní konverzní nástroj uměl odesílat konverzní doložky do IS Czech POINTu. Takže i tady zřejmě existuje dobře utajované veřejné API.
Takže si dovolím spekulovat, že autorizované konverze na tučném Czech POINTu funguje úplně stejně – tedy že používá nějaké veřejné rozhraní.
Jak tomu je skutečně, se, doufám, brzy dozvím, protože vnitro už vydalo novou vyhlášku se seznamem kontaktních míst (platná od 20. 10. 2009), na jejímž základě bude Pošta úředníkům kontaktních míst rozesílat vstupní údaje do systému. Sranda ale je, že školení těchto úředníků ještě neproběhla, protože obce s rozšířenou působností, které mají školit, ještě neví jak školit. Takže de jure Czech POINTy na úřadech mají fungovat, ale de facto není k nim obsluha.
Jinak nevím, jestli to je nová chyba nebo vlastnost, ale mně z Linuxu interaktivní webové rozhraní ostrého ISDS klidně pustí dovnitř, aniž bych měl nainstalovaný Filler a jeho zásuvný modul. Přitom když jsem to před týdnem zkoušel z Windows, tak bez Filleru ani ránu. Třeba se Filler začíná vytrácet :D
Oficiální adresa je https://www.mojedatovaschranka.cz/, odkud vás to už protáhne přes autentizační server login.mojedatovaschranka.cz a zase zpátky.
Včera jsem jim posílal pár chybových hlášení, mezi nimi je nutné mít povolené ukládání cookies po dobu relace pro obě domény (www.mojedatovaschranka.cz a login.mojedatovaschranka.cz). Rovněž předpokládám, že tam mají nějaké ošklivé javascripty, takže i jejich interpret musí fungovat.
Celé jsem to zkoušel na Firefoxu 3.5.3 v Gentoo, žádný XML Form Filler nemám nainstalovaný.
Je taky možné, že blbne nějaký měřicí kód, já jich mám hodně zablokovaných na proxy.
Ale jak koukám, momentálně to mají nějaké líné. (Třeba do testovacího prostředí, nevím jak moc je hardwarově svázané s ostrým, trvá přihlášení až 10 sekund.)
Teď jsem zakládal DS pro jednu organizaci. Pomocí FF3 ve WinXP. Vyřvávalo to na mě že chce 602XMLFiller, pak to na mě vyřvávalo že chce novou verzi XMLFilleru, pak že nemám adminovská práva, abych ho mohl nainstalovat. Poslušně jsem plnil všechny požadavky a při snaze zaregistrovat pověřenou osobu to najednou zase chtělo instalaci XMLFilleru.... Pak to na mě vyblekotalo další hlášky a když jsem vám ten text chtěl zkopírovat tak jsem zjistil, že to není text, ale objekt
object id="XMLFiller" width="100%" height="100%" param_ver_win="3,12,5,0" data="https://www.mojedatovaschranka.cz/portal/ISDS/pages/addDbUserContent.jsp?uid=12566775540721316846702" param_appaccpar="cry:BxIzFGxsUdX4umY38wYCJ/O35ncml+dHdxeHl3e3NgfWc1c3hrJm15a3YhJCV4fHMpJWEsMmB2fztxbmspLzYufGV3ZSkoPSg6OHxhNyw/Lj0vNik3Kz8mJTUxJzg3bywg" param_closeappurl="https://www.mojedatovaschranka.cz/portal/ISDS/index.jsp?nav=settings" name="XMLFiller" codebase="https://www.mojedatovaschranka.cz/static/pages/isds/xpi/602xmlfiller.xpi" type="application/x-filler-plugin"/
Kvůli 3 řádkům prostého textu tam udělají tohle. To je ale mentalita. Nakonec jsem to vzal OCRkem: Stránka vyžaduje novější verzi doplňku prohlížeče (602XML Filler). Abyste mohli dále pokračovat je potřeba provést jeho aktualizaci.
Takže po instalaci a aktualizaci, zase chce aktualizaci.
Mám další problém. Jazyk C(++) nemá žádnou implicitní znakovou sadu. Jak má knihovna předávat aplikaci řetězce? Bude toto předmětem zadání?
Klasický unixový přístup je, že se jedná o kódování poplatné aktuálnímu locale. To sice na moderních distribucích Linuxu nepředstavuje problém, protože ty jedou v UTF-8, ale pokud máme myslet na přenositelnost, tak to problém je. Obzvlášť když uvážíme, že z ISDS může přijít text s prakticky libovolným Unicode znakem, ale takový uživatel ISO-8859-2 nebo cp1250 systému bude mít problém tyto znaky vůbec nějak reprezentovat. (Prakticky řečeno převod z UTF-8 XML do kódování locale v knihovně může selhat, v lepším případě bude ztrátový.) Takto se chová například glibc nebo gettext.
Novější céčkový přístup je vracet řetězce jako řetězce širokých znaků. Nicméně pro aplikaci to může znamenat extra práci při převodu do kódování locale, aby mohla uživateli informace zobrazit. Navíc to není moc používaný způsob.
Třetí možnost je vymyslet si vlastní standard, který se často objevuje v nových linuxových knihovnách – knihovna vrací char* vždy obsahující UTF-8 řetězec bez ohledu na locale. (Například libxml2 tak funguje.)
Jaký přístup by byl nejlepší? A neříkejte, že to má být konfigurovatelné ;(.
(Poznámka: Úplně stejný problém je při ladicích hlášeních knihovny, když má citovat XML. Horší je jen o to, že tady jsou všechny přístupy špatně: Když nepřevede do locale, tak na výstupu bude smetí nebo to sejme terminál. Když převede, tak se ztratí fyzická struktura XML, což kazí ladění.)
http://www.recomando.cz/software
Tiskni
Sdílej:
