Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Vizte článek Projekt datové schránky: 2. fáze – zadání ze 4. 11. 2009.
Datová schránka je elektronické úložiště, které je určeno k doručování a k provádění úkonů vůči orgánům veřejné moci. Datovou schránku zřizuje a spravuje Ministerstvo vnitra. Pomocí datové schránky je možné posílat a přijímat úřední dokumenty v elektronické podobě (datové zprávy). Tento způsob komunikace nahrazuje klasický způsob doručování v listinné podobě. Pokud si tedy založíte datovou schránku, bude se vám většina korespondence od orgánů veřejné moci doručovat elektronicky. Datové schránky vznikly v souladu se zákonem č. 300/2008 Sb. v aktuálním znění. (Zdroj: datoveschranky.info)
Celý systém datových schránek je značně závislý na aplikaci 602XML Filler. Aplikace zpracovává soubory ve formátu (komprimovaného) XML, který popisuje strukturu formuláře odesílaného na server. 602XML Filler, což je nesvobodný uzavřený software, byl dlouho k dispozici pouze pro systém Windows, ale protože limitace povinného systému na jeden operační systém není možná, byla stvořena verze pro Linux a Mac OS X. Naneštěstí je podpora alternativních systémů řešena pouze pomocí emulace prostředí Windows (systém Wine), nikoliv nativními programy. Kromě toho je nabízena pouze verze pro 32bitové systémy, takže pro běh na dnes rozšířených 64bitových instalacích je nutné, aby systém obsahoval 32bitové knihovny pro zpětnou kompatibilitu. (Zdroj: Datové schránky v Linuxu)
Současný stav považujeme za nevyhovující, a proto jsme se rozhodli podniknout kroky k nápravě. Cílem našeho snažení je vydat open source/svobodné (GPL, BSD apod.) nástroje potřebné k tomu, aby bylo možné datové schránky používat a ovládat bez ohledu na použitý operační systém. Vyhlašujeme tedy projekt, jehož výstupem bude níže specifikovaný software. Doufáme, že se tak svobodnému softwaru podaří odpovědět na proprietární řešení, např. to od Microsoftu (Microsoft umožní pracovat s datovými schránkami pod Outlookem a Sharepointem).
V této počáteční fázi hledáme programátory, kteří by měli zájem se ujmout tohoto úkolu. Může se jednat o jednotlivce i skupiny. Finanční odměna bude udělena za odevzdání hotového produktu, který bude odpovídat definovaným požadavkům a úspěšně projde testem funkčnosti. Nejedná se o soutěž; pokud se najde větší počet zájemců o realizaci, byli bychom raději, kdyby spolupracovali. AbcLinuxu.cz je připraveno práci na projektu koordinovat, pokud to bude potřeba. Kontaktujte prosím redakci, chcete-li se na projektu podílet (redakce AT abclinuxu.cz).
Pro snadnou komunikaci a shromažďování potřebných informací jsme založili skupinu Datové schránky, která poskytne wiki a diskusní fórum. Vyzýváme také čtenáře AbcLinuxu.cz, aby v této wiki shromáždili co nejvíce informací, odkazů (na stránky v rámci AbcLinuxu.cz i externí) a dalších údajů, které mohou být při implementaci užitečné. Čím více toho bude na jednom místě, tím lépe se bude postupovat.
aplikace:
základní funkce:
pokročilé funkce (nejsou součástí základního zadání):
Portál AbcLinuxu.cz a Liberix, o. p. s., dají 5 a 3 tisíce Kč (tj. 8 000,- dohromady) za úspěšné zpracování zadání, které bude odevzdáno do konce roku 2009. Uvítáme, pokud se k iniciativě připojí další organizace nebo jednotlivci a pomohou s propagací, přispějí na vyšší odměnu nebo jinak přiblíží projekt ke kýženému cíli.
NOVÉ:
Finance projektu spravuje obecně prospěšná organizace Liberix. Když poukážete částku na její účet, bude tam čekat až do chvíle, kdy se organizátoři rozhodnou vyplatit odměnu úspěšnému řešiteli (nebo odměnu rozdělit mezi více řešitelů). V případě, že by se nepodařilo dosáhnout cíle, budou vám peníze vráceny (nebo jejich poměrná část, pokud by byla využita jen část fondu).
Potřebné údaje:
Další informace ohledně příspěvků bude Liberix poskytovat na info AT liberix.cz a čísle +420 595 175 184.
Jakmile peníze odešlete, pošlete prosím zprávu na adresu redakce, abychom vás mohli zařadit do seznamu subjektů, které projekt finančně podpoří: http://www.abclinuxu.cz/datove-schranky/wiki/odmena.
Pokud vás tento projekt zaujal nebo myslíte, že by vám či jiným mohl pomoci, pomozte nám s propagací. Napište o této iniciativě do blogu, upozorněte přátele, známé, spolužáky. Máte-li možnost vystavit na webu reklamní banner, využijte prosím grafická upoutávková tlačítka níže (budeme postupně doplňovat).
Vizte článek Projekt datové schránky: 2. fáze – zadání ze 4. 11. 2009.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Mno, hlavně že si to vůbec můžou udělat sami. Spoustu státních řešení spočívá v proprietárních softwarech, rozdíl je v tom, že někde je kvůli binárnímu typu dat, skoro znemožněno používat jinou aplikaci než tu původní.
Kontaktujte redakci, viz wiki stránka Odměna
To je velmi dobrý nápad a záslužná práce. Nechtěli byste zřídit otevřené konto, kam by se posílali penízky na tento projekt a případně na další podobné v budoucnu? Nevím, jestli je 8 tisíc dostatečná motivace (i když proč ne, jistě by se na to někdo vrhl i zadaro).
Podle mne ta relativne nizka castka je naopak zajimava z toho pohledu, ze bude pri funkcnim reseni kontrastovat s naklady oficialniho polofunkcniho reseni. Ono aby to bylo zajimavy pro programatorsky tym na plny uvazek vcetne otestovani tak tipuju, ze by se to muselo pohybovat trochu jinde. Ale o tom to tady asi opravdu neni.
Blbosť - vačšina ľudí nerobí testerov a ak už robia tak nie príliš radi a dobre (stači si pozrieť bugzillu)
prave ze nic, proto je to nejlepsi startovni pozice pro ty co chtej do IT a nerozumi mu:)
Teď příjde na to čemu říkáte testování. Pro datové schránky neexistuje testovací prostředí, nelze ani vytvářet a zasílat nějaké "testovací zprávy" mezi sebou - pouze úřad - osoba, vše jede na ostrých datech. Takže ono testování taky může vypadat v tomto stylu "Do opensource aplikace se nenačetla zpráva o soudním rozhodnutí, nemohl jsem se odvolat, následně na mě byla uvalena exekuce, přišel jsem o auto, dům, všechny peníze...Co mám dělat????
Testovacie prostredie samozrejme existuje, czebox.cz
dobry den,
jak je prosim adresa na Redakci? http://www.abclinuxu.cz/redakce jsem nenasel nic, pouze maily na jednotlive osoby, jeste mene informaci bylo na strance http://www.abclinuxu.cz/datove-schranky/wiki/odmena. Velmi rad bych prispel na tento projekt.
Dekuji
printf je line-buffered ... opravte si reklamu :-/
Skvělé!!! Díky
Zajímavé! Jsou někde k dispozici specifikace k příslušným protokolům? Je to variace na téma IMAP nebo něco takového?
Současný stav považujeme za nevyhovující, a proto jsme se rozhodli podniknout kroky k nápravě.Odvážnemu šťastie praje. Nemajte ale veľké oči. Programátorov schopných niečo také dávať dohromady nájdete (z ~2000 návštevníkov abclinuxu.cz) asi tak 20. Z toho 18 sa bude radšej venovať niečomu inému. Sorry, v tomto som dosť pesimista.
... za úspěšné zpracování zadání, které bude odevzdáno do konce roku 2009.Šibeničný termín. Jedine, že by si to zobralo pár vysokoškolákov, ako diplomovku a mohli sa tomu venovať viac ako pár hodín v týždni. Btw, nápad kontaktovať nejakú školu zameranú na IT a navrhnúť to ako tému diplomovky nie je, imho, až taký zlý.
Jsou někde k dispozici specifikace k příslušným protokolům?Presne. To je základ.
Šibeničný termín.Do konce roku jen zadání. Teprve pak se začne se samotným vývojem.
Pro mne je limitující spíše ta cena. Abych nechal normální práce a dělal tohle, tak potřebuji taky nějak zaplatit nájem.
To neni pravda. 602xmlfiller je velka obecna GUI aplikace, zde jde o vyplneni, podepsani a odeslani jedineho predem daneho XML.
Služba slouží ke stažení přijaté datové zprávy podepsané elektronickým podpisem MV formátu PKCS#7. Kompletní podepsaná zpráva je vrácena jako binární data a je na klientské aplikaci, aby si sama binární obálku podpisu po ověření odstranila a obsah přečetla.
Obsah zprávy po odstranění podpisu je totožný s popisem u MessageDownload, pouze s odlišným namespace „isds.czebox.cz/v20/message“. Pokud budete validovat výsledné XML proti XSD, musíte řetězec „/message“ odmazat.
Staženou podepsanou zprávu umí 602XMLFiller analyzovat a otevřít (díky namespace). Přitom zobrazí údaje o podpisu a o časovém razítku. Aplikace třetích stran mohou pro totéž použít např. MS Crypto API pro Windows nebo OpenSSL API pro Linux. Stažená zpráva NENÍ ve formátu fo nebo zfo (XML formulář), jedná se pouze o XML data.
Dovoluji si nesouhlasit. Dle mého je rozdíl mezi tím co chtěli a co dostali. Proto tam byl nesmyslný požadavek, který vyústil ve Filler. Protože to řešení který dostali by se IMHO dalo realizovat mnohem snadněji javou nad browserem.
Je to SOAP. Takže posílání a přijímaní XML přes HTTPS.
mozna byste mohli pro tento projekt ziskat podporu ceske piratske strany.
lidi si stezujou na ignoraci open-source statni spravou a politickymi stranami, pirati jsou sance na cestu z tunelu.
ee, pravda:(
Co je to za pubertální názor? Politika, to nejsou strejdové v televizi a předvolební mítinky na náměstí. Politika jsou prostě všechny "věci společné", včetně i toho, zda a jak bude ve státní správě podporován opensource. Politika je už i to, občas si zkontrolovat, co dělají zastupitelé za Vaše peníze. Politika je už i někam poslat novináře či policii. Politika je napsat petici či aspoň zvednou telefon a zvolenému zástupci vynadat. Takže už dost té pasivity a trošku aktivněji... Jinak je to opravdu tlachání k pivu...
Hail to the savior.
Hallowed are the Ori, hallowed are the Ori...
Pokud by to schválilo vedení, tak bych mohli projekt podpořit finančně, ale jak už tu někdo psal, není zrovna toto vhodné téma pro politizovnání.
Samozrejme dalsi darci jsou zvani. Nicmene ta odmena je jen tresnicka na dortu, mezi FOSS developery existuje jina motivace. Proto prepocitavat odmenu na hodinovou sazbu postrada smysl.
U me je to ten samy duvod.
Komerčný FOSS má šancu tam, kde potrebuješ podporu (SuSe/RHEL, JBoss, ...) alebo neustály prísun aktualizácií (napr.reflektovať zmeny v legislatíve). V tomto prípade nejaký skutočne komerčný model budeš tažko hľadať, keďže máš k dispozícii alternatívu zdarma, ktorá pre >95% užívateľov bude stačiť.
Práve preto je super, že autori na tom mysleli a tento donate-ware by mohol vyjsť.
Možná by nebylo od věci zkusit zadání projektu (a celou snahu) více zviditelnitKromě toho, že v tomto ohledu doufáme v pomoc čtenářů, tak jsme otevřeni návrhům na další vhodné cesty zviditelnění, které lze použít.
Můžete to nějak vystavit na ten váš facebookTam už zmínka je. Leoš navrhuje založit ještě samostatnou stránku na FB pro tento projekt...
Druhou možností je dát vědět o projektu Ministerstvu vnitra jako zřizovateli službyZajímavé. Ale zkusit to můžeme.
Další možností je upozornit co nejvíce (dalo by se říct zpřátelených) webů, např. ITbiz, root.cz apod.To je samozřejmost
Zajímavé. Ale zkusit to můžeme.A eventuelně jim navrhnout, že by na to mohli dát nějakou korunu. (Pravděpodobně by stačilo 1% z toho, co už dali
Tak pro všechny, kteří by se do projektu chtěli zapojit:
- dokumentaci k webovým službám najdete třeba zde: http://www.datoveschranky.info/priloha/100/
- budete zřejmě potřebovat knihovny minimálně pro práci se: SOAP, ASN-1 DER en/de-coding, OpenSSL (X509, signing)
- přečtěte si pečlivě veškerou legislativu týkající se DS, abyste rozuměli hlavním pojmům (jako DM, DB, doručenka, dodejka, ověřený podpis, kvalifikovaná časová známka, atp.) a principům doručování a ověřování
Osobně si myslím, že požadavek na rozšíření GUI Thunderbirdu je dost restriktivní, neznám v okolí nikoho, kdo by do rozšiřování Thunderbirdu viděl.
Tak jest.
SOAP => projekt gSOAP - po podhodení WSDL to vie vygenerovať multiplaformné zdrojáky pre C/C++ (a iné). Mám s tým dobrú skúsenosť (vrátane použitia proxy, a https) (debugovanie vnutri gSOAP nie je moc príjemné, ale spravidla sa ukázalo ako nepotrebné). OpenSSL - veci okolo šifrovania, podpisovania a overovania isto obsahuje. Otázne je ako dobre je to dokumentované. Ešte šťastie, že sú k tomu zdrojáky.- budete zřejmě potřebovat knihovny minimálně pro práci se: SOAP, ASN-1 DER en/de-coding, OpenSSL (X509, signing)Dal jsem před chvílí potřebné odkazy na Wiki.
Celá naše firma. OE byl vždy děravý a neimplementoval dobře IMAP a velký Outook tu nikdo nepotřebuje a nebudeme kvůli němu kupovat Office. Spouta lidí v okolí co jsou na Win TB má, čistí Linuxáci to možná vidí jinak, ale i tak bych si tipnul, že instalací TB je řádově více než Evolutionu, KMailu a kdoví čeho ještě dohromady.
Protože naše firma jede na linuxu, tak máme též thunderbird. A spokojenost je mnohem větší než s Outlook Express, který byl před tím, když se jelo na XP. V souvislosti s plánovaným ukončením podpory pro XP se hledalo řešení a proto se přešlo na openSUSE.
Naše firma používá Thunderbird také. MS Outlook často padal, docházelo k chybám souboru s e-maily atd. Nevyplatí se nám každé 2 roky kupovat nové licence. Na TB spravujeme desítky e-malových účtů jak v POP3 tak IMAP, já osobně mám v poště cca 100 000 e-mailů, stovky složek a vše funguje, problémů opravdu minimálně. Spokojenost.
Dokument, který byl dodán do datové schránky, je doručen okamžikem, kdy se do datové schránky přihlásí osoba, která má s ohledem na rozsah svého oprávnění přístup k dodanému dokumentu.
Tak řešení je vůbec se nepřihlašovat, pokud přijde oznamovací mail, že do schránky něco přišlo. Snad v tom mailu je i adresát, doufám.
Vůbec tomu sice nerozumím, ale tady http://egg.trask.cz nabízejí něco s těma schránkama a prý je to open source, třeba by to šlo ňák využít.
Byl jsem na semináři, kde Trask prezentoval toto řešení. Jedná se o Java systém postavený na JBoss aplikačním serveru a volitelně Alfresco DMS. Licencováno je to pod LGPL. Pokud vím, tak to zatím bylo distribuováno pouze účstníkům těchto seminářů na DVD formou VMware image, ve kterém je možno systém spustit a kde jsou také zdrojové kódy. Zatím jsem systém nezkoušel, ale působilo to na mne poměrně promyšleně a modulárně.
Osobně bych doporučoval se obrátit na Trask a pomoci jim se standartnější distribucí, otevření se externím vývojářům a propagací v free/open-source komunitě než zakládat konkurenční projekt.
ja o tech datovych schrankach moc nevim a proto jsem si ze zajmem precetl, co ta relativne velka firma o tom (a sobe pise). Prece jenom je videt, ze vic hlav vic vymysli, pisou v tom clanku, ze nabizeji v tom svem reseni napr. trideni doslych zprav podle odesilatele. To je velkolepa vec a cloveku je hned tak prijemne a je hrdy na to, ze patri k narodu, ktery dokaze vyprodukovat takove spicky. A to nemluvim vubec o tom, ze pry dokonce dokazi upozornovat na dosle zpravy a hlidat terminy. Ok, vsemu clovek verit nemusi, v reklame si mohou dovolit trochu prehanet.
Skutečně jsem jediný kdo přemýšlí o zablokování těch jejich suprových Datových schránek pomocí nějakého DDoS?
Pokud chceš vypadat jako totální idiot, pak s chutí do toho. I když pochybuju, že na to máš koule
Proč jako učil lidi dělat s IDE? Vždyť se to pak budou muset odnaučovat
A co jste chtel slyset potomNějak nechápu. Já nechtěl slyšet vůbec nic. Já si chtěl jen zahulákat.
Uvazujte jako projektovy managerNo tak já osobně doufám, že tak nikdy v životě uvažovat nebudu. Ale kdo ví.
a ne s klapkami typu linux a vse okolo je coolAle já neříkal, že je nehorázné to, že to není pro GNU/Linux.
pozde a jiz zbytecne. Tvrde receno: zaspali jste dobu.Tato iniciativa není závod. Je to reakce (a ta už z definice přichází až po akci) na dosavadní neutěšený vývoj v této oblasti. Nejprve neschopná oficiální "linuxová" podpora, potom proprietární řešení vázaná na konkrétní proprietární produkty. Tento projekt je snaha o nápravu, nikoliv honička za prvním místem.
Velka cast lidi asi popremysli o tomto: http://www.microsoft.com/cze/datoveschranky/ , nez aby pouzivala multiplatformni reseni.Protože zatím žádné pořádné multiplatformní řešení není. Až bude, tak budou možná (někteří) uvažovat jinak. Kdybychom s s tvojí argumentací přistupovali ke všemu, žádný svobodný software by asi nikdy nevznikl.
Kdyz chcete nekam davat penize, tak do vyvoje kancelarskych baliku - importni a exportni filtry.V tuto chvíli nám datové schránky připadají jako palčivější problém.
1) narazim na to, ze implementace a sireni produktu ma svuj cas. A neni dobre jej prosvihnout.Ano, bývalo by bylo lepší začít dříve. Ale pozdě není. Proč? Protože teď je první vlna. Později přijde druhá - to až bude povinnost rozšířena na podnikající fyzické osoby (a jsem si jist, že to přijde). A to už pozdě nebude.
Ono by to chtelo doimplementovat PKI infrastrukturu a renderovani (idealne standartizaci) formatu od 602-jky do kancelarskych baliku/knihoven.To by sice chtělo, ale ohledně standardizace je to trochu problém. Jaký standard by to měl být? Pokud nebude mezinárodní (ať už na úrovni ISO/IEC, IETF nebo třeba W3C), nikdo ho nebude brát vážně a bude to skoro, jako kdyby nebyl.
Právě že úloha není podatelna, ale především ona knihovna. Udělat na ni ksicht nebo propojení do něčeho jiného (Robert navrhoval Thunderbird) je okrajová záležitost plná politiky (GTK nebo QT).
Podatelnu bez napojení na ISDS neuděláte, knihovnu k ISDS bez podatelny uděláte, navíc ji vyžije více lidí. Hlavě lidí. Firmy/úřady si ji mohou začlenit do své podatelny. Kvůli datovým schránkám si podatelnu pořizovat nebudou/nemusí.
S PKI si teď hraju a jako vítěz vychází gnugp-2/gpgsm:
gpgsm: Podpis vytvořen 2009-09-11 11:42:16 pomocí certifikátu s ID 0x31478690 dirmngr[10904]: zaveden důvěryhodný certifikát „/home/petr/.gnupg/trusted-certs/postsignum_qca_sub-2009.der“ dirmngr[10904]: otisk SHA1 = 1B:DB:87:C4:81:02:97:7C:A2:77:65:E9:CC:A4:14:24:6C:6D:88:A2 dirmngr[10904]: vydavatel = #1C/[ 43 4E 3D 50 6F 73 74 53 69 67 6E 75 6D 20 52 6F 6F 74 20 51 43 41 2C 4F 3D C4 8C 65 73 6B C3 A1 20 70 6F C5 A1 74 61 5C 2C 20 73 2E 70 2E 20 5B 49 C4 8C 20 34 37 31 31 34 39 38 33 5D 2C 43 3D 43 5A ] dirmngr[10904]: subjekt = /[ 43 4E 3D 50 6F 73 74 53 69 67 6E 75 6D 20 51 75 61 6C 69 66 69 65 64 20 43 41 2C 4F 3D C4 8C 65 73 6B C3 A1 20 70 6F C5 A1 74 61 5C 2C 20 73 2E 70 2E 20 5B 49 C4 8C 20 34 37 31 31 34 39 38 33 5D 2C 43 3D 43 5A ] dirmngr[10904]: zaveden důvěryhodný certifikát „/home/petr/.gnupg/trusted-certs/postsignum_qca_root-2009.der“ dirmngr[10904]: otisk SHA1 = AF:3B:84:BA:34:37:63:BB:BE:03:6C:76:5A:44:11:9E:48:B5:2D:34 dirmngr[10904]: vydavatel = #01/[ 43 4E 3D 50 6F 73 74 53 69 67 6E 75 6D 20 52 6F 6F 74 20 51 43 41 2C 4F 3D C4 8C 65 73 6B C3 A1 20 70 6F C5 A1 74 61 5C 2C 20 73 2E 70 2E 20 5B 49 C4 8C 20 34 37 31 31 34 39 38 33 5D 2C 43 3D 43 5A ] dirmngr[10904]: subjekt = /[ 43 4E 3D 50 6F 73 74 53 69 67 6E 75 6D 20 52 6F 6F 74 20 51 43 41 2C 4F 3D C4 8C 65 73 6B C3 A1 20 70 6F C5 A1 74 61 5C 2C 20 73 2E 70 2E 20 5B 49 C4 8C 20 34 37 31 31 34 39 38 33 5D 2C 43 3D 43 5A ] dirmngr[10904]: trvale zavedených certifikátů: 2 dirmngr[10904]: za běhu nakešovaných certifikátů: 0 dirmngr[10904]: otevírá se kešový soubor „/home/petr/.gnupg/dirmngr-cache.d/crl-1958CDB7CC15F5A779E4E8324908508636F772AB.db“ dirmngr[10904]: S/N 0x042653 is valid, it is not listed in the CRL gpgsm: poznámka: nekritické certifikační politiky nejsou dovoleny dirmngr[10904]: otevírá se kešový soubor „/home/petr/.gnupg/dirmngr-cache.d/crl-B7A0ACF9BAD347177CDD34DD60E771EE09565B7C.db“ dirmngr[10904]: S/N 0x1C is valid, it is not listed in the CRL gpgsm: poznámka: nekritické certifikační politiky nejsou dovoleny dirmngr[10904]: S/N 0x01 is valid, it is not listed in the CRL gpgsm: Dobrý podpis od "/CN=Jana Svetlá/OU=1/OU=Czech POINT/O=Obec Úherčice [IČ 43500081]/C=CZ/T=úředník obecního úřadu/SerialNumber=P120293" gpgsm: alias "ouuhercice@quick.cz" gpgsm: Toto je kvalifikovaný podpis gpgsm: Vezměte na vědomí, že tento software není oficiálně schválený k vytváření nebo ověřování takových podpisů.
Včera jsem si vyjasňoval některé věci s pracovní skupinou PKIX IETF, takže poopravím dirmngr a tady jsme hotovi.
Tedy ještě zbývají razítka.
Spíš mně dostalo, že dle posledního znění zákona o elektronickém podpisu jsou kvalifikované podpisy všechny, jejichž certifikáty byly jako kvalifikované vydány v EU. Já mám problém ověřit kořen eIdentity, protože mají pobočky jen v Praze, a jak mám ověřovat zahraniční autority? Kdybych připustil, že obecně není nutné uznávat zahraniční CA (kvůli faktické nemožnosti ověřit kořen), pak bychom ovšem museli indukcí dojít, že není nutné uznávat všechny české a až absurdum není nutné uznávat jakoukoliv. Jinak řečeno faktická nevymahatelnost digitálního podpisu. Detail, že z kvalifikovaného certifikátu není možné bez soudního příkazu vytáhnout identitu jeho držitele, tedy vlastně není možné určit, kdo se nám podepsal, je už jen kopanec do mrtvoly.
Jistě že je pohodlné mít podatelnu, ale pro práci s ISDS to není nutné. Prostě když budu chtít zprávu zachovat, tak si ji uložím k sobě na disk. Funkci podatelny může zastat ta nástavba. Ale cpát funkcionalitu do knihovny, která má být jen API k ISDS je fakt nevhodné.
Každá země má seznam svých autorit. Ale aby stál za něco, musel by být podepsaný. Ne jako to má naše vnitro, že tam certifikáty jen tak pohozený. To už bych si je mohl rovnou stahovat z webů autorit bez dalšího ověření. Zajímavé je, že CERTy si své PGP klíče vzájemně podepisují, tak proč by to sakra nešlo tady.
Co to tady plácáš? Mám přemýšlet o produktu Microsoftu? To budou dělat verzi pro linux?
A myslím, že asi nejsem jedinej, kdo nemá win..
Nechápu souvislost. To je jen pro Widle, ne?
Ministersva vnitra ČR(← zkopírováno z www.datoveschranky.info – ani zadavatele si neumí pořádně pojmenovat, za ty prachy), protože to už by opravdu nebyla ostuda, to už by se asi něco takového asi ani nedalo slušně pojmenovat. Ale pro případ, že by se něco podobného opravdu začalo realizovat, bylo by možné založit právě ten transparentní účet nebo něco takového? Osobně bych odeslal na
Ministersvo vnitra ČRdopis s jeho číslem a pěknou kupou nadávek.
Nemyslím si, že je úplne nereálne to zvládnuť a dokonca mať z toho viac ako pri vykladaní banánov v Tescu. Ale C/C++ je na niečo takéto úplne nevhodné, hlavne keď požadujeme, aby to fungovalo kde-kade. Osobne by som sa prihováral za Javu, alebo nejaký skriptovací jazyk (perl?/python?). Ak by sa zmenili podmienky, tak by som nad tým snáď uvažoval.
Užívateľom je použitý jazyk úplne ukradnutý. Už dnes existujú rozšírenie do Thunerbirdu, ktoré sú napísané v Jave.
Ja to C/C++ trochu ovládam, preto si myslím, že problém bude práve urobiť skutočne funkčnú knižnicu, ktorá pobeží všade. Na to ako sa to líši len vo Win-Linux sa snaží pozrieť na TB/FF/OO.org .. Spraviť rozhrania pre iný jazyk tiež nie je problém. Práca s web services je však určite pohodlnejšia.
Bolo by krásne keby sa problém prejavoval len na úrovni UI, ale problém je obvykle omnoho hlbšie. Naklikať tomu nové GUI skutočne nie je problém, to súhlasím.
Ja to C/C++ trochu ovládam, preto si myslím, že problém bude práve urobiť skutočne funkčnú knižnicu, ktorá pobeží všade.V tom vůbec problém není. C++ je na tohle skutečně nejvhodnější.
Portoval si rozumne veľký kus kódu v C++ z Linuxu na Windows, alebo naopak?
Ano. Hello word
Nechápu, proč zrovna Java by měla odrazovat uživatele. Pokud se aplikace napíše dobře, tak v rychlosti není rozdíl a GUI se dá integrovat natolik, že jí steží rozeznáte od nativní aplikace. Takže kde je problém, v komplexech?
Který program v Javě toto dělá? Používám muCommander, Esmsku a NetBeans a ani jeden z nich tolik paměti nebere, natož aby mě brzdil počítač. Naopak po přidání flagu -XX:+UseCompressedOop je provádění programu ještě svižnější...
No, ono ale záleží kde ta Java běží. Když začnu s Windows, tak na XP je to tragédie, ale například u Windows 7 se mi systémový vzhled docela líbil. U Linuxu je to těžké, tam je pořádně podporované akorát Gnome a to ještě s rezervou. Do třetice všeho dobrého je tu Mac OS X. Tam je integrace do systému excelentní, ale programátor musí tyto možnosti znát a umět je použít. Poté může vypadat program například takto.
Nepochybuj o tom, že nemálo ľudí by sa rozhodlo, že existujúce riešenia nie sú ideálne a potrebujeme niečo nové :)
WSDL → obálka pro C++ → obálka pro JNI → Java
asi těžko přinese nějakou výhodu oproti WSDL → obálka pro Javu
. A podobně s dalšími jazyky, které mají už implementaci SOAP v sobě, a je jednodušší použít tu, než přikládat nativní knihovny pro různé platformy a řešit napojení na onen nativní kód. Kód v C++ se hodí pro případ, kdy má být i klientská část v C/C++ (teda třeba ten Thunderbird nebo KMail). Pokud by ale klientská část byla v jiném jazyce, C++ knihovna nepřináší žádnou výhodu, spíš naopak.
WSDL → obálka pro Javu
jsi omezen jen na platformu Javu a GUI. Jakmile někde není Java nebo GUI, bude tato aplikace nepoužitelná. V čem je WSDL → obálka pro Javu
lepší než WSDL → obálka pro C++/Qt
nebo WSDL → obálka pro C/GTK+
, případně WSDL → obálka pro C/C++/CLI
? Multiplatformní jsou všechny. Navíc Ty v C/C++ nejsou závislé na Javě.
A vy to budete programovat, ze tak propagujete Javu?
Uprimne receno je mi z toho Java hype uz blbe, staci mi to na fakulte od vyucujicich a ted to jeste mam cist tady (ja vim, nikdo me nenuti).
To je pro me nova informace, v tom pripade by mohlo byt nejjednodussi pouzit jiz hotovou praci i kdyz bych radsi videl nativni reseni, tomuto duvodu se nebranim.
Prosim vsecky flamery na tema java, at si zalozi vlastni vlakno, nejlepe v blogu a tam si to vyrikaji, z klavesnice do klavesnice a touto offtopic debatou nezaneraduji puvodni tema. Dekuji.
Asi jste nepochopil, k čemu jsou frameworky dobré. Samozřejmě, že je možné psát vše v assembleru, ale vývoj něco stojí – takže se občas vyplatí znovu použít nějaký již dříve napsaný kód. Tím kódem jsou třeba kompilátory vyšší programovacích jazyků, knihovny a frameworky.To samozřejmě chápu, o tom žádná. Diskuse je o tom, kdy použít jen (nativní) knihovny a kdy frameworky. O assembleru jsem ani nepíp...
Takže „s frameworkem X se mi dobře programuje“ je velice pádný důvod (v podstatě jediný důvod, podle kterého se framework/jazyk/knihovna vybírá), přebít to může jedině případ, kdy onen framework nejde z nějakého důvodu použít (např. není dostupný na cílové platformě).To je otázka. „S frameworkem X se mi dobře programuje“ je pádný důvod, pokud to nějaké firmě ušetří netriviální množství člověkotýdnů práce. V takovém případě je jen logické, že ona firma zvolí platformu X.
Diskuse je o tom, kdy použít jen (nativní) knihovny a kdy frameworky. O assembleru jsem ani nepíp...Jenže to je pouze otázka měřítka. Úplně stejné argumenty, jaké máte vy proti frameworkům, může mít někdo jiný proti C nebo C++ – opět tam je něco „navíc“, co programátorovi ulehčuje práci, ale přidává další závislosti.
To je otázka. „S frameworkem X se mi dobře programuje“ je pádný důvod, pokud to nějaké firmě ušetří netriviální množství člověkotýdnů práce. V takovém případě je jen logické, že ona firma zvolí platformu X.To samé ale platí i pro OSS, i tam je užitečné ušetřit zbytečnou práci a věnovat se třeba zlepšování programu. A použití dobrých frameworků ušetří práci téměř vždy – musíte dělat něco opravdu výjimečného, aby se vyplatilo psát si framework znova. Ono není samo s sebou, že se od strojového kódu dostáváme stále k vyšším a vyšším programovacím jazykům, od sdílených částí kódu ke knihovnám a frameworkům – ono znovu použití kódu totiž opravdu usnadňuje práci a zlepšuje výsledný kód, protože při používání společného knihovny máte zadarmo i opravy od všech těch, kteří knihovnu používají také.
JRE má nainstalované skoro každý...
Hahahaha, tak takhle jsem se dlouho nezasmál Promiňte, teď k věci. JRE má nainstalováno pouze 10% uživatelů počítačů. Jsou jím majitelé Mac OS X. Žádný jiný systém dodnes nedokázal zajistit, aby byla Java standardně předinstalována. Tolik k realitě. Pro ty méně důvtipné: Javu vám nikdo nebude jen tak používat, protože si jí musí oněch 90% lidí nainstalovat, což není dobrá vizitka pro Sun (nebo dnes již Oracle?).
To je sice moc hezké, ale já to myslím tak, že předinstalovanou Javu má pouze 10% uživatelů počítačů. To je také to, co ve zbytku komentáře zmiňuji. Nenapadlo by mě hledat zastoupení nainstalované Javy podle nějakých průzkumů uživatelů internetu. Už jenom kvuli tomu, že si jí někteří uživatelé vypínají spolu s dalšími pluginy. Krom toho to není kvalifikovaný odhad, ale všeobecně známý fakt. To s tím OpenSolarisem jsem plácnul už jen tak od boku, protože rád provokuji Nicmémě, je-li to tak jak říkáte, pak 80% uživatelů má tedy Javu nainstalovanou, což je docela úspěch. Na to, že oněch 70% uživatelů si jí musí instalovat a updatovat ručně...
JRE má nainstalováno pouze 10% uživatelů počítačů.
Protože jsem jantar Všiml jsem si to i u komentáře podtím. Ostatně, nevěděl jsem, že má Java takhle velké zastoupení. Abych byl upřímný, nikdy jsem si to nezjišťoval. Vycházel jsem z faktu, že předinstalovaná je na minimu počítačů. Protože kdykoliv jsem se ptal někoho zda má Javu, řekl že ne, případně že se mu jí nechce instalovat. Což je také věc, která mě moc netěší. Stále totiž neplatí úplně pravidlo "Write once, run anywhere". To může být pravda až tehdy, kdy bude Java standardně nainstalovaná na Linuxu i na Windows... No, člověk se pořád učí, takže vím zase něco nového
Nejsem si jistý, zda to byl úplně správný příklad s Firefoxem. Neboť na každém OS je standardně nějaký webový prohlížeč nainstalován. Alespoň že tak. Avšak Java už bohužel ne, ačkoliv je to velmi vhodný prostředek pro spoustu řešení. A vzhledem k tomu jak je široce používaná mi přijde dost nelogické, že dodnes není standardně předinstalována na Windows. Těch pár mega nikoho nezabije, protože samotný systém zabírá mnohem více. A přední Linuxové distribuce pro desktop by jí měly mít nainstalovánu také. Vždyť přece existuje OpenJDK, tak v čem je problém? Takhle když píšu program v Javě, tak opravdu jediný systém na který je spoleh je holt Mac OS X. Jinde prostě musíte počítat s tím, že tam Java není, musíte vytvářet bat, exe nebo sh soubory na spuštění, atp.
Teď nevím, co tím přesně myslíš. Tu Javu od MS, která byla ještě příšernější než od Sunu, ale nakonec jí zakázali? Nebo je to nějaká nová feature, co umí spustit applet, ale ne desktopovou aplikaci?
Java SE Runtime Environment 6u16
jre-6u16-linux-x64.bin
19.33 MB
ps: není to málo, ale není to 90, tak nepindej blobosti
Na druhú stranu:
chio@xxx:~$ du -h /usr/lib64/jvm/java-6-sun/jre/
...
92M /usr/lib64/jvm/java-6-sun/jre/
sun-java6-bin Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files) 86,6 MB sun-java6-jre Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files) 14,7 MB + závislosti
Máte samozřejmě pravdu - jeden o voze a já, zcela očividně, o koze.
Omlouvám se kralyk-ovi za to "pindání blbostí".
QT je take multiplatformni reseni.
Nejdriv sem mel podobny nazor (ohledne jazyka), ale aby se vysledny produkt dobre pouzival, je opravdu nejvhodnejsi zaintegrovat ho do postvniho klienta/prohlizece. Muj primarni jazyk je java, ale tezko budu v jave delat plugin pro firefox/thunderbird/kmail/...
To je podle mě práce navíc a zbytečné nároky na znalost Pythonu.
Podle toho, co jsem se zde o technologické stránce věci dověděl, se domnívám, že tvořit prototyp je vzhledem k rozsahu a náročnosti zbytečné. (Ale jak říkám, mám o tom jen informace z této diskuze a navíc ani nemám příslušné vzdělání nebo zkušenosti.)
proboha, javu ne! tech radoby multiplatformnich aplikaci psanych v jave, ktere funguji podle toho, jaka verze javy je zrovna v systemu nainstalovana, jsem videl uz dostOsobne by som sa prihováral za Javu
C++ aplikácií, ktoré je potrebné meniť s novou verziu gcc podľa mňa nebude menej :)
Overené, ale dovody sa mi hľadať nechce. V každom prípade je to kompilované bez pedantic a ansi, prechod len medzi verziami g++ (prvá verzia napísaná pred 10-12 rokmi). A je možné, že by sa to s nimi nestalo.
Celkem souhlasím, podle mě připadá v úvahu Java nebo C++/Qt. Na thunderbird bych se úplně vykašlal, protože podle mě chcou mít lidi hlavně možnost využít datové schránky, integraci bych řešil, až bude hotová první verze.
Existuje vec ktera mi na jave nevyhovuje => nejsem cilova skupina.
To jsou mi zajimave uvahy.
Já si myslím, že je naprostý nesmysl nejdříve vybírat technologii a potom teprve zjišťovat co ten program vlastně má dělat. Z komentářů jsem se dozvěděl, že termín vytvoření zadání projektu je do konce roku. Proč je tedy už teď vybraná technologie pomocí které se to bude implementovat? Nejdříve má vzniknout analýza a teprve na jejím základě vybrat nejvhodnější technologii. Jiný postup zavání tím, že do projektu někdo vnáší svoje osobní emoce(jako tady v diskuzi). Zvlášť u projektu tohoto typu by se měl brát hlavně ohled na uživatele a ne na vývojáře jinak to nikdo používat nebude.
Zvlášť u projektu tohoto typu by se měl brát hlavně ohled na uživatele a ne na vývojáře jinak to nikdo používat nebude.To se týká tak možná komerčních projektů, kde to přinese zpět nějaký bakšiš. Ale proč bych se při vývoji OSS měl ohlížet na nějaké uživatele a ne na to, jak to vyhovuje mně, to nevím
Ale proč bych se při vývoji OSS měl ohlížet na nějaké uživatele a ne na to, jak to vyhovuje mně, to nevímPokud se bavíme o projektu tohoto typu, tak ten je pro uživatele. Jakmile bude přizpůsoben vývojářů, je na nejlepší cestě k tomu být jen pro smích uživatelům mainstreamové konfigurace systému (Windows, 32 bitů), kterým je jedno, jak prasácké to je, ale hlavně že to nějak funguje a je to user-friendly.
Proč byl zvolen Thunderbird? Chápu, že poštovní klient je nejbližší nástroj, který se používá každý den, ale obávám se, že integrace bude obtížná nebo zbytečná.
Proč? Protože buďto to bude v podstatě nezávislý xulový program, který se jen zobrazuje v Thunderbirdu, takže se stejně bude muset udělat celá logika pošty (správa zpráv) znovu, nebo bude nutné se hrabat do C++ kódu Thunderbirdu, protože pochybuji, že je připraven pro dopisování transportních backendů (IMAP, maildir) formou modulů.
Rád bych se pletl, ale obávám se horšího scénáře.
Ví někdo, jak na tom Thunderbird je?
To zas ty kaprici pro NOVELL A T602 nebo jak se ta organizace jmenuje.....
Paráda, jen jsem zvědav, jestli se budou lidi schopní domluvit, jestli to bude Qt nebo Gtk aplikace
Ta knihovna by mela byt asi minimum zavislosti (v ramci moznosti), cim mene, tim jednoduseji pujde zkompilovat "skoro vsude" :)To já jsem zas zcela opačného názoru. Pokud se někdo dílčímu úkolu věnuje, tak většinou mnohem lépe. A ještě se šetří pamětí. A závislosti jsou úkol pro balíčkovací systém, tak proč se s tím cpát?
Neni problem napsat knihovnu zcela bez Qt...Jistěže není, ale pokud nechci psát od začátku funkce pro HTTP(S) komunikaci, tak potřebuju nějakou knihovní třídu - např. tohle vyřeší věci okolo HTTPS za mě. OK, uznávám, že program pro KDE, který si v závislostech přitáhne i půlku Gnome, z toho být nemusí, ale za každou cenu se vyhýbat knihovnám je zbytečné. Zmíněné Qt (jak je to u ostatních knihoven nevím) vyřeší na Linuxu balíčkovací systém a ve Windows se ke knihovně přibalí pár DLL.
A až bude chtít někdo klienta na mobilním telefonu, tak co?Qt přestalo fungovat na mobilních telefonech?
Zrovna HTTPS bych řešil přes curl (250 KiB) nebo neon (131 KiB).Klidně. Proč ne. Já nechci tvrdit, že bez Qt to nejde, prostě jenom nadhazuju možnou cestu.
Ale ona ani ta implementace od nuly by nebyla marnáNIH syndrom nebo jenom snaha přidělat si spoustu práce a projekt, který by bylo záhodno mít brzy hotový, dostat do použitelného stavu za pět let nejdřív? Neříkám, že tudy cesta nevede, ale přijde mi, že tolik dobrovolníků se asi nenajde, aby měli čas implementovat knihovní funkce. (A taky se mi nelíbí mít v systému tři knihovny, pročemž si každá bude řešit věci po svém. Ale to už je odbočka směrem k flamu o tom, jestli si programy mají balit knihovny s sebou)
To by bylo moc práce a spotřebovalo by to příliš času a energie. Myslím, že opravdu by bylo vhodné přinejmenším alespoň zvážit použití gsoap toolkitu jak tu psal už rastos. Kupodivu to zůstalo bez jakékoliv reakce.
Výhody:
Nevýhody:
tak teda to jako za toto maximalne palec nahoru a +10.000.000 bodu.
Stat selhava, jak videt obcane prebiraji ulohu statu protoze nic jineho nezbyva protoze stat neni jako opet schopen niceho uzitecneho. Tyjo kam jsme to dopracovali. Tady je neco velmi spatne a neco se musi hodne rychle zmenit. Na tomto prikladu je to naprosto jasne videt.
To je divné, domníval jsem se, že Filler potřebuji i když na to lezu Firefoxem.
Asi je to všeobecně známé, ale možná by se leccos vykoukalo z enigmailu, rozšíření thunderbirdu pro PGP. Pokud by byly binárky typu gpg, openssl atd., pak by se to dalo snadno volat ze všeho možného, třeba z toho javascriptu TB. Je mi jasné, že tak jednoduché to nebude ...
Podívejme se na práci s datovými schránkami z jiného pohledu:
Multiplatformnost je hezká věc, ale má jedno velké úskalí, kterým je přístupnost pro odečítače obrazovky neboli screen-readery jako NVDA ve Windows nebo Orca v Linuxu. Ve Windows jsem už chtěl zrakově postiženým lidem instalovat nejeden program, který používám v Linuxu. U windowsích verzí však narážím na nedostatek podpory pro takzvané asistenční technologie. Výjimkami jsou Firefox a Thunderbird verze 3.x, VLC media player, Esmska a OpenOffice. U řady dalších programů si odečítač obrazovky takříkajíc „ani neškrtne“.
Kvůli přístupnosti dávám před multiplatformním programem přednost zásuvnému modulu pro Thunderbird, který je odečítačům obrazovky dobře přístupný ve windowsí i linuxové verzi.
Super! Jenom zamrzí člověka, že vlastně někdo bude dělat práci, kterou měl zařídit a zaplatit stát.
Webová aplikace je nepříliš vhodná pro odečítače obrazovky. I když je stránka dobře strukturovaná, není pohyb po ní triviální. Zkuste se s pomocí odečítače obrazovky orientovat ve schránce jakéhokoli freemailu jako například Seznam a „uvidíte“ Rychlost práce v poštovním klientovi se s webem nedá srovnat, o komfortu ani nemluvě.
Doufam, ze neco takoveho nevznikne a z projektu datovych schranek bude prodnej prusvih. Neco jako portal verejne spravy co taky pomaloucku po lehoucky vysumnelo do ztracena. Datove schrankly jsou uklazkou diletanstvi s prvky standartni politicke lumparny od sameho pocatku. Jednim slovem ZLO. Zrusit bez nahrady je jedinny systemove spravny postup.
Jen dotaz... Proč nutně C nebo C++?
Když už jsme u těch technologií... Zajímalo by mě, jestli existují lidé (a pokud ano, tak kolik) schopní (za daných podmínek) relativně kvalitně vyvíjet pro platformu Thunderbird.
A jinak, anketa by se měla omezit jen na ty, kteří datové schránky využívají (nebo budou využívat). Takhle každý hejhula (včetně mě) hlasoval pro to, co "by mu asi připadalo nejlepší, voe".
A otázka by spíš měla být:
Jaké uživatelské rozhraní preferujete? (možno zadat více možností)
a) samostatná nová aplikace
b) rozšíření nějaké existující samostatné aplikace (jaké?)
c) webová aplikace
... technologie by se měly řešit až po tom, co budeme vědět, o jaký výrobek je vůbec zájem.
Jaké uživatelské rozhraní preferujete? (možno zadat více možností) a) samostatná nová aplikace b) rozšíření nějaké existující samostatné aplikace (jaké?) c) webová aplikaceJá si hlavně myslím, že nejlepší by byla knihovna/CLI program, nad kterým by se potom stavělo dál.
To už je ale záležitost rozčlenění té aplikace. Rozdělit to na části je vcelku logické.
(A v té mnou navrhované anketě chybí ještě d) něco jiného.)
A mimochodem, co se stalo s tou slavnou open-source spisovkou, jejíž součástí je integrace s ISDS?Testuje se, testuje se, ale v ostrém provozu, pokud vím, není. Ale není to nic než jakási PHP aplikace, nic ohromujícího.
kontaktujte našeho zástupce.
O mesiac mozno dostane naspat peniazeA deset let k tomu. Když nastoupila Prasolánkova vláda, tak jsem si říkal, že Pospíšil je tam jedinej, co dělá něco slušnýho. Taky mu to moc nevydrželo.
Navrhni ...
Můj návrh je tady:
Každopádně Leoš a Robert jako iniciátoři mají hlavní slovo.
Nebo jeste lepe, davejte to do wiki a do skupiny. Neni to dokonala forma, ale muze dobre slouzit pro synchronizaci nazoru. A jestli do ni vlozite ODF dokument nebo mind mapu, je uplne jedno. Prilohy tam snad jdou uploadovat, mate k dispozici wiki, diskuse a dokonce i redakcni system pro publikovani clanku. Ty dobre pak Robert muze vytahnout na uvodni stranku.
Snad se něco změní , stejně toto vše začne za 14 dní a dle mne to skončí velkou ostudou ....
Ahoj,
varování: jsem Slovák, ale v práci píši česky, tak to zkusím i tady (tímto se předem omlouvám za pravopisné chyby).
Pokusím se jako člověk z projektové praxe od klientů této snaze nastavit zrcadlo a možná i trochu pomoct.
Roberte, super nápad! Cením si již v úvodu uvedenou podporu firem - bude se hodit v případě garance (oprava chyb, změnové požadavky), jak zmiňoval goldenfish.
Rád se přidám k realizaci a jestli se přidá i někdo další, minimálně se spolu něco o projektech v OSS prostředí naučíme. PS: a vůbec nejvíce se naučíme, když to bude fakt propadák
Ale postupně:
1. Co mi chybí je pořádné zadání. Ne typu bude to C++ nebo java, nebo klient/server (tady stále anketa nepomáhá, že jo), ale co to má řešit, pro kolik uživatelů, pro jaké platformy, požadavky na GUI, sizing, ... Tohle zmiňoval bořek, freshmouse nebo i vencas. Tohle i navrhuji jako první krok.
Ono je to vlastně úplně jednoduché - jak zjistíš (např. ty jako zadavatel) nebo komunita, že jsi dosáhl cíle? Minimálně, že jsme na správné cestě?
2. Navrhuji aby postupně byly věci dávané na wiki. Zatím nevím přesně, jak to funguje (Leoši, jak se na wiki přidá stránka - tohle je user frendly? Nebo jako na Wikipédií?).
Každopádně: hlavní stránka je: https://www.abclinuxu.cz/datove-schranky/wiki.
Navrhuji aby někdo (kdo ví, jak udělat v ABCLinuxu wiki novou stránku udělal následující členění:
Zbytek klidně jako samostatné stránky:
3.Tým
Je to OSS projekt a jak hodně lidí poznamenalo, motivace je někde jinde. Proto si Roberte dobře promysli, jak odměnu rozdělíš a současně nikoho nedemotivuješ ... Tohle teďka nechme stranou.
Abychom začal v týmu od sebe:
Tým (inspiraci jsem našel ve výše uvedené diskuzi dle jednotlivých reakcí):
Tak jo, vyčerpal jsem se, Roberte, komunita, zkusíme to?
Presne tak. Jen admin skupiny smi vytvaret ci mazat podstranky, je to ochrana pred vandaly a dale moznost spravcu ridit si podobu wiki. Vsichni realni zajemci, hlaste se, udelam vas adminy.
Zdravim
tiez by som chcel prispiet, mozte so mnou ratat pri kodovani nizkourovnovych veci ( C, C++).
Rad sa nieco nove naucim
Marek
..Ne typu bude to C++ ..
no moc zkusenosti asi nemate, jinak byste vedel, ze ten pozadavek C/C++ je stezejni, aby se hned od zacatku vyloucili vsichni ti Javisti, pythonisti, vyznavaci php a podobni. Ten projekt ma byt totiz hotov jeste letos.
> Tohle zmiňoval bořek, freshmouse nebo i vencas. Tohle i navrhuji jako první krok.
Já bych dodal, že asi nejdůležitější informací v mém příspěvku bylo, že tady vášnivě diskutuje spoustu kluků, co je nějaké datové schránky nezajímají ani jako uživatele, ani jako vývojáře. Tím se dostáváme na úroveň diskuze o tom, "kerý Linuxy sou jako ty nejlepčejší". Ten něco udělal v Javě, tak by "se to mělo" udělat v Javě. Támhleten používá KDE, takže je Qt jasná volba. A tuhle Karel zase používá poštovní klient XYZ, takže "by mělo" vzniknout rozšíření pro něj. Atd.
Taky máme zadání, že má vzniknout jakási knihovna v C nebo C++ a jakési rozšíření pro Thunderbird.
Já bych ale spíš chtěl slyšet názor někoho, kdo ty schránky používá. Jak to chce. Jak to nechce. A jestli to vůbec chce! To je přeci základ; až pak se můžeme bavit o jazyku nebo platformě.
Tedy, ještě před zadáním potřebujeme znát názory.
Nejhloupější komentář dne:
u open-source neni treba platit testery, ty jsou vsude delaj radi a "zdarma" ....
(multi)
Nemám co dodat.
> Já bych dodal, že asi nejdůležitější informací v mém příspěvku bylo, že tady vášnivě diskutuje spoustu kluků, co je nějaké datové schránky nezajímají ani jako uživatele, ani jako vývojáře. Tím se dostáváme na úroveň diskuze o tom, "kerý Linuxy sou jako ty nejlepčejší". Ten něco udělal v Javě, tak by "se to mělo" udělat v Javě. Támhleten používá KDE, takže je Qt jasná volba. A tuhle Karel zase používá poštovní klient XYZ, takže "by mělo" vzniknout rozšíření pro něj. Atd.
pěkně, souhlas ...
> Taky máme zadání, že má vzniknout jakási knihovna v C nebo C++ a jakési rozšíření pro Thunderbird.
> Já bych ale spíš chtěl slyšet názor někoho, kdo ty schránky používá. Jak to chce. Jak to nechce. A jestli to vůbec chce! To je přeci základ; až pak se můžeme bavit o jazyku nebo platformě.
> Tedy, ještě před zadáním potřebujeme znát názory.
K tomuhle následující. Robert píše: "Cílem našeho snažení je vydat open source/svobodné (GPL, BSD apod.) nástroje potřebné k tomu, aby bylo možné datové schránky používat a ovládat bez ohledu na použitý operační systém". Já bych ještě dodal "s možností archivace, jak píše goldfish, protože těla správ se mažou po 90 dnech ze schránky. Zůstávají jenom hlavičky.
Roberte - jak se stavíš k zadání a cíli?
Datové schránky dosud nepoužíváme, ale budeme muset. Než instalovat 32bitový bastl s přibaleným WINE, to už raději do schránky polezu přes virtualizované XP, které máme na jednom stroji. Iniciativa platformě nezávislého řešení mě mile překvapila, jsme malá firmička a naše možnosti nejsou neomezené, ale myslím, že bych vydupal i nějaký bakšiš na finanční podporu tohoto projektu - myslím, že transparentní účet je dobrý nápad. Také rád pomohu s otestováním čehokoliv, bohužel kvalitním kódem přispět nedokážeme. Co se provedení týče, jako uživatelům nám nezáleží na jazyce, obecně by však absence javy jako závislosti nebyla na škodu. Na poštu používáme KMail, Thunderbird ne-e, ale chápu, že někdo jiný zase používá Thunderbird a další zase Evolution, nevím co obnáší technicky vytvoření pluginů pro vícero poštovních programů, pokud je to složité, hlasuji pro samostatnou aplikaci, instalovat Thunderbird kvůli datovým schránkám i tam kde se jinak nepoužívá mi připadá nešikovné.
Souhlas, veskera technicka diskuse necht se presune do diskusniho fora ve skupine. Zalozte si tam dotazy na volbu programovaciho jazyka, architekturu atd.
To uz jsme ted Jenom resime organizacni zalezitosti. Krome nabidky financi v redakci prispela nabidka jedne firmy na dva programatory a dozvedeli jsme se o podobne aktivite, se kterou by se to dalo snad propojit.
Jaký provozovatel by pak byl důvěryhodný?Takový, který bude dostatečně důvěryhodný. Jaká je záruka, že něco takového nedělá třeba ICZ u svého hostovaného řešení e-spis lite? To je úplně totéž.
Především zákon říká: Osoba oprávněná k přístupu do datové schránky je povinna zacházet s přístupovými údaji tak, aby nemohlo dojít k jejich zneužití.
Tedy ne že nedojde, ale by ani nemohlo. Tudíž předávat takové údaje třetí straně je přinejmenším na pováženou.
Ten termin je dost sibenicni.
...zpracování zadání, které bude odevzdáno do konce roku 2009
Zkusím odpovědět na pár dotazů, které se zde opakují:
Sami používáme thunderbird (win i lin), ale přesto bych se přikláněl k CLI aplikaci + JS rozšíření do TB (pokud API TB umožní potřebné úpravy), které by mohlo posloužit jako námět pro extenze do jiných mailových klientů/samostatnou GUI aplikaci. Obávám se, že řešení přímo v TB neumožní snadné následné "vykostění" do samostatné knihovny.
Navíc CLI aplikace umožní automatizované nasazení (servery, embedded routery, atd.), skriptování atd.
Navíc CLI aplikace umožní automatizované nasazení (servery, embedded routery, atd.), skriptování atd.Ještě někdo napíše jak by se mu to nejvíc hodilo a jak by to chtěl použít a … a už se do toho asi fakt vložím. Není to snad v případě existence nějaké knihovny a zdokumentovaného API úplně jedno? To už by měl snad zvládnout kdejaký bastlič si tu CLI aplikaci na to naklikat, ne?
CLI nebo knihovna je samozřejmě fuk, hlavně aby to mělo zdokumentované API a šlo to snadno ze TB vytáhnout. Což vůbec není samozřejmé, pokud by se to psalo rovnou pro TB.
Nemohla by ta knihovna posktytovat IMAP / POP3 či maildir rozhraní? Prostě bych v libovolném poštovním klientu se přihlásil k IMAP účtu na localhostu (nebo na svém serveru). Při kontrole pošty přes IMAP by tak naše knihovna kontaktovala DS a případně vrátila novou zprávu. Taková jako proxy.
Nikde jsem ve wiki nenašel odkaz na MDC https://developer.mozilla.org/cs/Hlavn%C3%AD_strana
Projektu velmi fandím. Je veliká škoda, že musíte dělat to, co nebyl schopen pohlídat stát jako zadavatel zakázky. Za 900M byto snad jít mělo. Ale jsme v ČR, země neomezených možností.
Na celé diskuzi mě udivuje dohadování se jestli to bude používat Qt, GTK nebo jestli to bude jen knihovna, druzí nadávají, že to nesmí být v Javě. Umět to a chtít se to toho po přečtení článku nějak pustit, asi by mě po přečtení diskuze přešla chuť. Pro Boha ať je to klidně Qt aplikace! Nebo GTK, to je vlastně jedno. Ti stěžovatelé s keci o natahování spousty knihoven mohou jít někam. To nikoho zajímat nebude! Prostě ať to chodí a pěkně vypadá. Není nutné mít GTK, QT, Motif a já nevím co ještě rozhraní. Stačí jedno ale chodivé! Hlavní požadavek je funkčnost a vzhled. Nebo mi chcete říct, že u programu sledujete které knihovny natahuje a pak nadáváte? Není to úchylka? Mě zajímá aby to chodilo, vyhovovalo mi to a je mi srdečně jedno jaké knihovny to tahá do paměti. Jestli se spouští o tři sekundy déle je mi u pr... . Stejněto spustím jednou a běží to celý den.
To se týká tak možná komerčních projektů, kde to přinese zpět nějaký bakšiš. Ale proč bych se při vývoji OSS měl ohlížet na nějaké uživatele a ne na to, jak to vyhovuje mně, to nevím.
Aha, tak už se nedivím proč některé linuxové aplikace tak vypadají. Udělám app která se hodí mě, chce ji používat někdo jiný, má připomínky ale kašlu na ně. Proč bych se měl ohlížet na uživatele, mě to tak vyhovuje. To je pěkná kravina. S tímto přístupem nebude nikdy nic pořádně. Snad svoji app vylepšuju a těší mě, že ji používají jiní (když už to teda dělám a zadarmo). Můj program taky používají jiní a pokud požádají o nějakou funkci, dodělám ji (pokud to umím).
Aha, tak už se nedivím proč některé linuxové aplikace tak vypadají. Udělám app která se hodí mě, chce ji používat někdo jiný, má připomínky ale kašlu na ně. Proč bych se měl ohlížet na uživatele, mě to tak vyhovuje. To je pěkná kravina.Důvod?
S tímto přístupem nebude nikdy nic pořádně.A to zajímá koho?
Aha, tak už se nedivím proč některé linuxové aplikace tak vypadají. Udělám app která se hodí mě, chce ji používat někdo jiný, má připomínky ale kašlu na ně. Proč bych se měl ohlížet na uživatele, mě to tak vyhovuje. To je pěkná kravina.Nevím, ještě moc programovat neumím, takže jsem moc patchů nikam neposílal, ale co jsem slyšel, tak pokud není úplně zprasený, tak ti ho obvykle začlení.
To nelze zobecňovat, záleží na konkrétním správci projektu.
Tipnul bych si, že např. u OpenOffice nebude jednoduché protlačit vůbec nějaký patch. Např. u alsy musí být patch hodně rozumný, jinak jej správce vrací k přepracování (včetně důsledného dodržování štábní kultury). Rovněž FFMpeg je pověstný přísnými správci.
Jde o uživatele, ne o programátory. Z obyčejného uživatele je problém dostat pořádné hlášení o chybě. Prostě pokud udělám app pro sebe a někde ji zveřejním, je jasné, že se časem začnou objeví lidi, kteří chtějí něco dodělat, něco poopravit a tak. Těmi lidmi myslím uživatele, ne programátory. Programátor si to dodělá, uživatel ne. Pokud nechci aby to používal někdo jiný, nezveřejňuji to nebo tam vysloveně napíšu, že se toho už nedotku. To ale nemůže být případ aplikace pro komunikaci s datovými schránkami.
Tou app samozřjmě nemyslím 5 řádků v bashi.
Je vyžadováno zobrazení a editace rich textu klinentem? Co je obsahem zpráv? Budou to primárně binární přílohy - DOC, PDF,.. nebo primárně je zpráva přímo formulářem používajícím nějakou formu rich textu?
Do jaké míry se bude podobat napsání klienta DS napsání pokročilého textového editoru? Editace zprávy je vyžadována v zadání a hádám, že plain textem dneska už tolik neokouzlíte, ani obchodní partnery ani státní orgány.
Pokud je rich text vyžadován, včetně editace, jaký formát musí klient umět?
Jaký formát předepisuje standard DS pro obsah zprávy? Čisté html? Proprietární XML based? RTF? ODF? OOXML?
Vyžadování nebo nevyžadování zobrazení a editace rich textu přímo v klientu má zásadní dopad na výběr klientské technologie. Existuje jen velmi málo free open source komponent pro zobrazení a editaci rich textu.
Java SWT (Eclipse RCP) - má dobře itegrovaný Gecko canvas včetně jeho editoru, třída class org.eclipse.epf.richtext.RichTextEditor. Gecko je sice halvně zobrazovač html rich textu ale má integrovaný editor - jsou na něm postaveny online web editory, NVU, Komposer, google doc, TB editor, Eclipse GUI designer atd.
Java Swing - JEditorPane. Analýza schopností? Existuje reálné použítí mimo demo samples? Asi by šlo použít i ten Gecko canvas, jako u SWT, ale pak proč nepoužít SWT rovnou.
Thunderbird - kvalita editoru rich textu zrovna nenadchne, žádná podpora editace tabulek či formulářů, TB nabízí v toolboxu jen nejzákladnější operace. Je to založené na Gecku, takže schopnisti by měly jít rozšířit (jak moc práce?)
Qt - má přibalený WebKit, jaké jsou editační schopnosti web kitu? Netuším. Analýza nutná.
KDE - canvas z KOffice/KWordu by měl být dobře použitelný i mimo KOffice (pomocí KParts). Schopnosti editace OK, ale jak zvládá formáty jiné než ODF?
Gtk - vysekat canvas s AbiWordu? Jde to? Už to někdo zkusil?
OOo - nepokročilejší editor, včetně tabulkového. Že by někdo úspěšně vysekal OOo canvas a použil jinde, nevím. Pochybuji, že by se to podařilo do vánoc. Schůdnější je varianta pluginu do OOo místo samostatné aplikace. Použitelná varianta pro případy kdy bude převažovat v obsahu DOC přílohy i samostaný rich text content.
Omlouvám se, moc dění okolo DS nesleduji. Bydlím trvale v zahraničí. Ptám se ze zvědavosti. Zarazilo mě, že problematiku editace rich textu nikdo neřešil i v tak dlouhé diskusi. Já to vidím jako hlavní problém.
Jestli jsem zprávně pochopil, tak nejvíce práce bude s vytvořením ekvivalentu aplikace 602XML Filler (klient). Udělal už někdo analýzu na čem je postaveno originální řešení od 602?
Společnost 602 je známá distribucí upravené OOo. Postavila i svůj filler na OOo? Alespoň částešně řekněme. Předpokládám, že má 602 komerční licenci od SUNu na OOo takže nemusí modifikace zveřejnit.
Naopak článek na abíčku o DS napovídá, že se jedná o plugin do Firefoxu! Zajímavé. Bohužel, článek se nijhak nevěnuje technologickému pozadí této linuxové implementace DS. Škoda.
Já nechci vyzývat k okopírování řešení od 602, ale pokud chcete mít použitelné řešení v co nejkratším termínu, pak by stálo se nad již hotovým řešením konkurence se alepoň zamyslet. Proč to tak řešili. Nedopustit se stejných chyb.
Podle screenshotu na http://www.602.cz/602xml/602xml_filler mám zato, že aplikace 602XML je primárně o práci s rich textem, to vidím jako hlavní zádrhel, tomu bych podřídíl výběr technologie (jazyka, knihoven komponent). Viz můj předchozí příspěvek.
Nebylo. Předpokládám, že se tím již někdo zabýval a třeba si udělal i pár poznámek, vidí do toho hloub, má přesné linky. Textu o DS je dost, času prokousat se tím je málo. Hlavně když jeden hledá informace na jaké se ptám (použité technologie..). Například zadavatelé projektu by řasu odpovědí mohli vědět přímo ;)
Zpracované odpovědi by se tak jako tak měly stát součástí projektového zadadání. To by se určitě mělo udělat, než se někdo překotně vrhne na implementaci. Není příjemné přijít v půlce práce na to, že zvolená platforma nemá použitelný rich text editor a že největší díl práce spočívá v programování textového editoru.
Jestli jsem zprávně pochopil, tak nejvíce práce bude s vytvořením ekvivalentu aplikace 602XML Filler (klient).Ne, nebude. Ta část, která se používá na datových schránkách, je jednoduchý formulář o maximálně tak dvaceti položkách, který by se dal snadno vytvořit v HTML. Druhá část pak je ověření elektronické značky a časového razítka.
Musím se přiznat že stále tápu co je obsahem "dokumetu (datové zprávy)" jak je specifikováno v http://www.datoveschranky.info.
a) je to metadata (ca 20 položek, formát v XML) plus binární příloha (DOC? PDF..)
b) je to metadata (ca 20 položek, formát v XML) plus plain text (obsah zprávy).
c) jen metadata (ca 20 položek, formát v XML), metadata jsou tím obsahem zprávy, sdělení (zpráva) je jednou z těch políček v XML. Čili zpráva je plain text (opravdu?). Přílohy se používají jen minimálně a má výrazně doplňový charakter.
> Druhá část pak je ověření elektronické značky a časového razítka.
Tomu rozumím.
Prosím, nějaké ty screeshoty z relevatní části XMLFilleru. Takový screenshot to je někdy za tisíc slov.
Nějaké ty příklady jaký text může ta zpráva nést? Něco jako "Podle rozhodnutí okresního soudu praragfu xyz/123 vám krámek včetně zboží zabaujeme. Váš Úředník Despota".
Jaká je očekáváná průměrná délka zpráva (jak velké okno na to bude potřeba), jak velké bude to textové okno. Jak znám úřední zprávy, to je A4 minimum.
V zadání chybí JavaScript jako implementační jazyk, pokud uvažujete o klientu nadstavbě (pluginu) pro Thunderbird. Řada řečníků si to asi neuvědomuje, ale pro Mozillu/Firefox/Thunderbird se primárně programuje v JavaScriptu, XUL, XBL a CSS, nikoliv v C/C++. Mrkněte se na zdrojáky Lightingu (link dole). Koneckonců sám Firefox je napsán primárně kombinací C++ a XUL, XBL, JavaScript a CSS. Celé UI je JS nad několika málo nativními komponentami (Gecko canvas a editor, data storage..).
Já bych ten projek vůbec pojal jako dvojprojekt pro minimálně 2 lidi (teamy).
1) Knihovna (+ daemon?) - implementace v C++ nebo Java.
2) Klient na bázi Thunderbirdu - implementace v JavaScript, XUL, XBL, CSS.
Protože málokdo je machr v obou technologických mixech, je to spíš záležitost pro nejméně dva lidi.
Odkazy:
http://mxr.mozilla.org/mozilla/source/calendar/ ..zdrojáky Lightning (Caledar rozšíření Thunderbid) rozsahem možná něco podobného jako klient k DS. Schválně kolik C/C++ tam najdete. Já zběžně nenašel ani řádku, zato tuny JS, XUL, CSS, a nějakou tu kapku ostatního (makefile, Perl, idl).
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure - něco více k source code tree Mozilla projektům. Zájemce o implementaci klienta může začít studovat.
Děkuji. Celou dobu se snažím říci, že implementace přímo v TB asi nebude to pravé ořechové, ale je potřeba nativní obecnou knihovnu (třeba i obalit do CLI), udělat vzorový plugin pro TB a pak to ostatní mohou okoukat a dopsat pluginy pro další emailové klienty. Je možné, že při implementaci klientů vznikne požadavek na rozšíření API, ale to je život.
A my celou dobu od zadani rikame, ze se ukol sklada ze dvou casti - knihovny poskytujici API pro praci s datovymi schrankami a pak implementaci pro thunderbird. Vzhledem k celkove vysi odmeny (upresnime snad zitra) tak nebude problem, aby se zucastnilo vice lidi, kazdy implementujici cast. Nekdo knihovnu, jiny Thunderbird rozsireni a treti treba samostatnou aplikaci. Tim vyhovime obema skupinam. Akorat mam potom strach z toho, jak odmenu spravedlive rozdelit (pocet radku, commitu, slozitost).
Prostředků k rozdělení: X Funkční blok A [ ] Funkční blok B [ ] Funkční blok C [ ] Funkční blok D [ ] Činnost E [ ] Činnost F [ ] sum = X
OK, díky moc.
10k, k stavajici odmene pro funkcni reseni pro Tbirda. Martin Kalenda, Nethost s.r.o
Dost bylo kecani, pojdme k veci. Ve skupine se rozrusta wiki a jsou zde diskuse k reseni (struktura wiki, Řešitelský tým, Poznatky a vědomosti a základní funkce).
Se zájmem jsem si přečetl celou diskusi a musím říci, že na mne udělala dojem. Vzniká projektový tým, sbírají se podklady pro upřesnění zadání, všechno vypadá vcelku nadějně. Ale důležité je, že i kdyby to nedopadlo, všichni se hodně naučí.
Svůj názor na datové schránky jsem napsal tady do blogu už včera. Když to hodně shrnu, zadavatel udělal neskutečnou chybu, že vůbec dopustil, aby existovala byť jen jediná možnost legálně nevyzvednout schránku. Ta chyba není v žádném případě na straně Linuxu.
Mne by ani nepřekvapilo, kdyby se nám již brzy snažil dodavatel systému datových schránek nabídnout nějaký kus kódu pro volné použití. Je dobře, že je tu tým odborníků, který by případně dokázal posoudit, zda je možné takový kód použít, zda je dostatečně okomentovaný, dokumentovaný, zda je zcela zřejmé, co dělá a zda je možné vůbec dát doporučení pro jeho všeobecné použití.
Nezapomeňte: Sovy nejsou tím, čím se zdají být
Nezkoumal někdo zda nemají DS nebo něco podobného v jiné zemi? Opravdu jsou Čechy první zemí kde něco takového implementují? Pokus to existuje i někde jinde, jaké programy na to používají? Neexistuje už náhodou použitelné open source řešení kdeteré by šlo zadaptovat na českou legislativu?
A pokud jsou Čechy opravdu průkopníkem, koncipovat zde vznikající řešení tak aby bylo použitelné i jinde = přilákat kodery i ze zahraničí? Čili česká specifika jako plugin, zdůraznit konfigurabilitu.
V čechách už open source řešení nezaboduje jako jedno z prvních, ale v cizině by stále ještě mohlo..
Mame napsanou aplikaci ISDS2Mail.
Dela to, ze periodicky kouka do datovych schranek (muze i do vice najednou):
- notifikuje Vas na email ( nebo i vic emailu pripadne SMS) o novych zpravach s detaily o co se jedna od koho atd.
- vybira to zpravy ze schranek a preposila je to na email a to vcetne originalni zpravy s casovym razitkem a separovanych priloh a souhrnu z hlavicky
- umi to ty zpravy tez ulozit na disk do definovaneho adresare
- je v Jave takze pobezi jak na Win tak na Linuxu, proste tam kde mate JRE
- lze to integrovat i jako serverove reseni napr. na email server
- neni potreba zadny plugin nebo neco podobneho do Utlouku a dalsich emailovych klientu, nejaky FormFillery atd.
Odesilani mame tez vyresene, ale to je jina kapitola.
Pokud to nekoho z Vas zaujalo, tak mi napiste na jabber vitezslav.kosina@hybrid-post.org pripadne email dtto.
VK
To zni skvele. Jaka je licence? Mohl byste to uvolnit pod FOSS licenci, abychom na vasi praci mohli navazat, preportovat do C/C++ a udelat GUI?
O tom mam prave pochyby. Bezny uzivatel potrebuje tlacitko ve sve oblibene aplikaci. Komunitu kolem tohoto portalu nepovazuju za bezne uzivatele, ti si mohou na zakladne vznikle knihovny vytvorit vlastni CLI rozhrani :-0
IMHO: nebojte, on na tom nekdo karieru postavi /driv nebo pozdeji/
Ty z části vycházejí z nedobrých zkušeností při vytváření již existujících řešení, nebo prototypů, z části z neblahých prognóz.
Na stránce http://www.abclinuxu.cz/datove-schranky/ je rozcestník k celému projektu, významná je i stránka požadavky na plánované řešení a k ní příslušná diskuze.
Díky za podporu.
Ač tu dobu tak trochu pamatuji (Gottwaldow přes ZPS lehká vazba na Slušovice), není v mých vzpomínkách tak hrozná a s nostalgií na ni vzpomínám, nelíbí se mi dnešní dění kolem datových schránek, ale snažíme se s tím, v rámci možností, vypořádat.
Víc než peníze na odměny hledáme nejlepší cesty jak tenhle projekt co nejlépe řídit, zakotvit ho do hlavního dění kolem datových schránek a zajistit mu podmínky pro budoucí rozvoj.
Centrum dění tohoto projektu je http://www.abclinuxu.cz/datove-schranky/.Zdravím. Tak už došlo i na Python jak tak vidím.
Přehodil jsem váš příspěvek do diskuze Existující řešení práce s DS
Přeji hodně zdaru.
Nevím, jestli dorazil můj e-mail s dalšími informacemi Písařovi dorazil.
V každém případě bych mu rád poděkoval za práci na projektu a ABCLinuxu za založení projektu.
Současnou verzi libisds se mi podařilo po mírném přiohnutí pro již postarší infrastruktury systému Debian Lenny zkompilovat a slinkovat s Shigofumi nadstavbou pro příkazovou řádku a výsledný program nám umožnil přijmout první datovou zprávu z ostrého ISDS prostředí, která nám byla úřady do firmy doručena.
Díky otevřenému projektu jsme se tedy nemuseli zabývat amatérsky řešeným a nebezpečným softwarem, jehož použití nám bylo vládními úřady vnucováno a které na 64-bit prostředí GNU/Linuxu stejně funkční není.
S pozdravem,
Pavel Píša
PiKRON, s.r.o.
http://www.pikron.com/