Synchronizace Akonadi jako téma školního projektu

Na portále kvalifikačních prací vypisovaných společností Red Hat se včera objevilo téma zajímavé pro příznivce KDE PIM: Data synchronization between multiple instances of Akonadi, které vypsal Dan Vrátil. Sháníte-li téma školní práce (nebo víte-li o někom), je to ideální příležitost, jak se zapojit do vývoje přímo pod vedením současného správce projektu Akonadi. A jste-li příznivci jiných technologií, ani další témata (a lidé za nimi) nejsou k zahození …

4.10.2013 14:22 | kavol | Komunita

Komentáře

[jkt]

Neprijde mi to jako stastny krok -- namisto synchronizace skutecnych ulozist (IMAP, CalDAV, CardDAV,...) se projekt snazi sychronizovat neco, co melo puvodne slouzit "jen jako cache".

[kavol]

Neprijde mi to jako stastny krok -- namisto synchronizace skutecnych ulozist (IMAP, CalDAV, CardDAV,...)

na to jsou jiné projekty

finta fň je v tom, že ty můžeš mít těch úložišť více různých, a teď máš zkonfigurované nějaké vlastní prostředí, které k nim nějak přistupuje - a ty chceš to prostředí přenést na jiný počítač (mobil, tablet ...), nikoli ta samotná úložiště

se projekt snazi sychronizovat neco, co melo puvodne slouzit "jen jako cache".

mno, tož o původních záměrech a designu atd. bych raději pomlčel; můj negativní názor na Akonadi je zde myslím všeobecně znám ... nicméně když už s tím musíme žít(*), považuju toto za velmi dobrý počin (ehm, tedy ... popravdě, Dana jsem o to požádal ) a fandím každé snaze staré chyby napravit, resp. Akonadi vylepšit

(*) pro pracovní potřeby, kde si vystačím s jedním IMAP účtem, docela spokojeně používám Trojitou, ale na doma to pro mě jaksi není, a co jsem měl pod rukou jiného, tak teda radši zkousnu KMail2 s Akonadi, než Thunderbird a jiné :-/

[s0]

Za podporu více účtů v trojité bych dal.. no, to ne, ale dal bych dost.

[dementni.lojzik]

dobry tema na vypsani bakalarky, ne? Nevim, kolik usili stoji vypsani prace na VS externi firmou, ale vzhledem k tomu, ze je i v zajmu skoly, aby studenti delali neco smyluplneho, a ne e-shop v PHP po 1001, tak by to mohlo stat min nez dost (pochopitelne chapu, ze jsme v Cechach, kde je obvykle vse naopak nez veli zdravy selsky rozum, takze by me ani neprekvapilo, kdyby to ve skutecnosti bylo velmi komplikovane/nakladne)

[karel]

Nejde jenom o to vypsat práci. Taky se těm studentům musí někdo věnovat. Pokud se tomu nevěnuje někdo ze zadavatelské firmy, tak nakonec mu ten výsledek bude nejspíš stejně k ničemu (student udělá úplně něco jiného než firma chtěla). Sice to vypadá super delegovat práci na studenty, ale v praxi je s tím dost práce na obou stranách. Mě se taková spolupráce líbí, ale je potřeba to promyslet a nejít do toho bezhlavě. Pak to často nedopadne dobře (ať už pro studenta tak pro firmu). Mnohem lepší je spolupráce v rámci nějakého většího grantu, kde se řeší víc projektů najednou a lidi jsou v užším kontaktu.

[Sešívaný]

Jak už psal kolega, je to především o závazku té firmy, že se tomu studentovi bude věnovat. Už jsme v Red Hatu vedli práce studentům z 11 VŠ v ČR a SR a nikde nebyl zásadní problém to domluvit. Naopak vedoucí ze školy byli rádi, že studenti budou dělat na něčem reálném a že s tím budou mít méně práce, protože prakticky všechny technické konzultace se odehrávají mezi studentem a vedoucím od nás.

[dementni.lojzik]

Jak už psal kolega, je to především o závazku té firmy, že se tomu studentovi bude věnovat.

tak to se pochopitelne mysli samo sebou

Už jsme v Red Hatu vedli práce studentům z 11 VŠ v ČR a SR a nikde nebyl zásadní problém to domluvit.

tak to rad slysim. Jen pak nechapu, proc to firmy masivne nevyuzivaji - aspon mam ten dojem (mozna mylny), ze to neni moc caste, ze firmy vypisuji nejake DP (ostatne, kdyz se divam na jednotlive kategorie v tom systemu, tak to vypada, soude podle poctu vypsanych temat, ze v RH se dela prevazne jboss/java )

[Rezza]

Jbossaci jsou jen hyperaktivni . Idealni je si z tech ostatnich vybrat oblast, kontaktovat toho, kdo to vypsal a pak se domluvit na tematu. Vetsinou se pak vymysli tema primo na miru. A je to sranda, pred sesti rokama jsem zacinal delat DP pro RH i ja a dnes mam puk za pet let ve zbrani na stole :)))).

[Michal Kubeček]

a dnes mam puk za pet let ve zbrani na stole

Nějak se mi nedaří tu větu rozparsovat. Mají slova "puk" a "zbraň" jiný význam než obvykle nebo je trik v něčem jiném?

[Michal Kubeček]

Aha, asi jsem si to špatně uzávorkoval. Varianta

dnes mam (puk za ((pet let) ve zbrani)) na stole

dává o poznání víc smyslu. :-)

[kavol]

Jen pak nechapu, proc to firmy masivne nevyuzivaji - aspon mam ten dojem (mozna mylny), ze to neni moc caste, ze firmy vypisuji nejake DP

protože to není taková sranda, jak to vypadá ... pro někoho může být problém třebas to, že je ta práce pak víceméně volně přístupná - což je fajn u opensource projektů, ale jinak moc ne

[Rezza]

I to je resitelne, ale pravda - s vetsi namahou.

[dementni.lojzik]

nevim, co fimy potrebuji tajit na takove urovni, ze by to byl blocker pro diplomku (ano, relevantni priklady se urcite najdou, ale IMHO jich neni vetsina), navic mluvim zejmena o open source projektech. AFAIK se dneska ve vetsi ci mensi mire OSS bezne ve firmach pouziva a ze firma XY pouziva pro buildovani projektu napr. maven nebude asi zadne prisne strezene tajemnstvi (napr. relativne nedavno jeden znamy nadaval, ze maven wagon nepodporuje kerberos autentizaci - IMHO by to na bakalarku mohlo vystacit nebo by se k tomu jeste pridala nejaka dalsi featura, ktera jim chybi). Nebo vyse - ze zamestanci pouzivaji jako mail klient trojitou asi taky nebude nic extra tajneho. Jediny potencialni problem jsou tupi studenti, kterym zamestnanec venuje hromadu casu, ale nic poradneho stejne neudelaji - to uz je ale riziko podnikani

[kavol]

ok, pochopil jsem to obecněji, sorry

máme-li se držet opensource, tak ... kolik znáš takových firem, které se nějak seriozně zabývají vývojem?

jak naznačuje okolní diskuse, ono to jaksi není o tom "potřebujeme funkci X, tak ať nám ji napíše nějaký student" ... a to tvoje "riziko podnikání" také není zcela nezanedbatelný problém (jak jsem slyšel od kolegy, co vede )

[dementni.lojzik]

máme-li se držet opensource, tak ... kolik znáš takových firem, které se nějak seriozně zabývají vývojem?

vyvojem nebo open source vyvojem? Pokud se mam omezit na CR, tak v prvnim pripade jich par bude, ve druhem uz tolik ne, ale pointa byla, ze i kdyz ty firmy delaji closed source vyvoj, velmi casto pouzivaji open source nastroje - daval jsem jako priklad maven i konkretni priklad, kdy jim chybi nejaka funkcionalita, ale nejak nechapu, ze by si to mohli napsat sami nebo by jim to dokonce mohl nekdo napsat vymenou za par hodin konzultaci.

jak naznačuje okolní diskuse, ono to jaksi není o tom "potřebujeme funkci X, tak ať nám ji napíše nějaký student"

v pripade bakalarek to velmi casto je jen tady o tom + text, ktery popisuje pouzite technolige, jaky problem se resil a proc se resil. Na diplomky temata typu "potrebujeme funkci X" obecne nejsou dostatecna, ale zas hromada lidi resi i slozitejsi problemy nez jen "potrebujeme funkci X".

... a to tvoje "riziko podnikání" také není zcela nezanedbatelný problém (jak jsem slyšel od kolegy, co vede )

odmitnout spolupraci s flakacem, co nic nedela neni problem (resp. je to problem jen toho studenta) a pripady, kdy je student tak extremne tupy, ze ani pri nadstandardni snaze ze strany vedouciho to nikam nevede, lze IMHO poznat hned pri prvnim rozhovoru a hned mu doporucit, at si vybere neco jineho. Toto snizuje riziko na IMHO prijatelnou mez.

[lertimir]

Firmy to nevyužívají masivně také proto, že cíle firmy jsou mnohdy jiné než cíle DP. Firmy často chtějí něco ve smyslu: Tady máš problém, takto to chceme zprogramovat a teď to udělej/zprogramuj. Ale to je neobhajitelná práce. Chybí v ní to, co vlastně má dělat vysokoškolák, analyzovat probém, posoudit možnosti řešení. Je tam jen, provést "nějaké" řešení. Pokud firma nejde do toho, aby student v rámci toho práce měl vlastní samostatnou práci, tak se práce nepodaří

[dementni.lojzik]

nevidim duvod, proc by studen nemohl zadany problem analyzovat a navrhnout vlastni reseni. Pokud bude jeho reseni prokazatelne lepsi nez to, jak si to predstavuje firma, muzou jen byt radi, ze nekdo vymyslel lepsi reseni.

[lertimir]

Souhlas, jen některé firmy si představují, že zadání takové prace je jen levná cesta nechat si zprogramovat to, co potřebují a když zjistí, že tak to není vycouvají.

[Fluttershy, yay!]

Lidi na kombinovaném/dálkovém prý celkem běžně dělají bakalářky v rámci svojí normální práce... To je vlastně ta poslední věta, že?

[Rezza]

To je pravda, kdyz vymyslime BP/DP, tak samozrejme rikam, ze je potreba mit neco, u ceho jde napsat Techickou zpravu. Coz je pak o to slozitejsi - ve skole chteji zpravu, ve firme pouzitelny vysledek. Dvakrat vic prace :).

[jkt]

Zcela realisticky vim, ze problem neni v penezich, ale v mnozstvi casu, ktere je clovek ochoten poskytnout. Nicmene nemam problem s vypsanim nejakeho kickstarteru ci podobne akce. Predpokladam, ze neplanujete venovat vlastni cas a doprogramovat to, takze se zeptam -- o jake castce se, orientacne, bavime?

(Jsem autorem Trojite.)

[Pali]

radši zkousnu KMail2 s Akonadi, než Thunderbird a jiné :-/

Toto mi pride dost divne. Preco nie potom KMail bez Akonadi?

[kavol]

no, protože udržovat aktuální systém se starým KMailem je poněkud problematické ... popravdě, nevím, jak je to aktuálně, leč v dobách, kdy jsem zmigroval (ehm, spíše byl zmigrován) na KMail2 ani snad nikdo starou verzi neudržoval, s Trinity mám dojem přišli o něco později ... a navíc starý KMail taky nefungoval ideálně (hlavně IMAP)

[Pali]

No nech sa snazim na to pozriet akokolvek state je KMail z KDE3 stabilnejsi, nez to s Akonadi... Naviac KMail do verzoe KDE4.4 nepouziva Akonadi az prilis a vdaka API/ABI kompatibilite KDE bude bezat aj na KDE 4.11

[kavol]

No nech sa snazim na to pozriet akokolvek state je KMail z KDE3 stabilnejsi, nez to s Akonadi...

YMMV ... já jsem hlavně naivně doufal, že se dětské nemoci vyřeší, no a když už jsem si zvyknul na nové chyby a nové workaroundy (dokonce už ani nemusím dělat to harakiri s několikerým restartem akonadiserveru, jak jsem tu popisoval asi před rokem), tak nemám valného důvodu a chuti migrovat zpět a řešit nco mimo standardní distribuční verze, takže jaksi již nemůžu srovnat, co z toho je aktuálně stabilnější

[R]

Stary KMail (1.9.10) ma svoje bugy, ale je pouzitelny. Pouzivam denne so 4 IMAP uctami.

[kavol]

Stary KMail (1.9.10) ma svoje bugy, ale je pouzitelny.

mezi "nefungoval ideálně" a "není použitelný" vidím jistý rozdíl, takže nevím, oč se tu přeme, má-li to tedy rozporovat moje tvrzení

Pouzivam denne so 4 IMAP uctami.

a kolik z nich je na serveru, který půlku protokolu implementuje blbě, upstream chyby neřeší, a když je omylem vyřeší, tak se patch nasadí tak možná za dva roky od vyřešení (ne nahlášení), a je schopen spadnut (resp. utnout spojení) například jen na tom, že jej požádáš o zprávy v jiném pořadí, než očekává (Zimbra)? - chápu, že jeden program nemůže (no, neměl by ...) řešit chyby druhého, nicméně dostává-li na vstupu něco, s čím se neumí vyrovnat, měl by zahlásit příslušnou chybu, a ne to nějak sežvejkat a pak někde později spadnout nebo odmítnou zobrazit/vymazat zprávu bez zjevné příčiny apod.

[Fluttershy, yay!]

Přibude tam ještě něco vypsaného i pro Olomouc, ideálně orientovaného na desktop?

[kavol]

a) nemám křišťálovou kouli, abych věděl, koho co napadne vypsat ... pokud máš o něco konkrétního zájem, nějaký nápad, můžeš ho navrhnout, třeba se najde někdo ochotný to zaštítit

b) nemůžu mluvit za Dana, ale počítám, že omezení na jednu školu v Brně je tam spíše omylem

nejlíp uděláš, pokud se obrátíš přímo na autora zadání nebo na admina (Sešívaný)

[Fluttershy, yay!]

No, loni dorazila výprava (vlastně vesměs místních, ehm) do školy. Tak by mě jenom zajímalo, jestli dorazí i letos. Do Brna by se mi fakt kvůli konzultacím dojíždět nechtělo. Stejně se zítra zeptám, pokud si na to vzpomenu.

(Tím netvrdím, že mám vysloveně zájem. První uvidím, jak dopadne můj vlastní návrh na téma přímo ve škole.)

[Hans1024]

Mozna byli loni tak ohromeni nasi pocetnou ucasti, ze zvazuji zda vubec prijet, abychom je neuslapali

[honza_c]

Mě v druháku v Olomouci čeká výběr bakalářky nejspíš na jaře. Vůbec nemám tušení, do čeho jít, vím jen, že se chci držet Linuxu, láká mě dění okolo KDE. Třeba něco vymyslím, ale nemám zkušenosti. Pokud bude zase nějaká přednáška Red Hatu na UPOLu stejně jako loni, určitě se přijdu podívat.

[Sešívaný]

Není problém přijít s vlastním tématem. Přímo v Olomouci je Lukáš Tinkl, který by ti to mohl vést. Všechno je o domluvě.

[pavlix]

Neřeš, co je jak vypsané, zapoj vlastní iniciativu. Popravdě řečeno redhaťákům je asi dost jedno, na které jsi škole, takže jde jen o to, jak je která škola ochotná spolupracovat.

[lertimir]

To vypadá zajímavě. Mám dojem, že Akonadi je BackEnd pro zaznamenávání tagovaných informací pro DigiKam. A myslím, že zatím není technika, která by umožnila synchronizaci těchto natagovaných věcí.

Typická situace: Na desktopu je uloženo, spravováno a tagováno hlavní úložiště fotek. Nicméně někde při cestách fotograf nafotí balík fotek, má čas tak je zpracuje hned na notebooku, ale po příchodu k desktopu není (nebo alespoň jsem zatím nenašel cestu), jak přenést z notebooku fotky včetně všech natagovaných informací, vzájemných vazeb. Akonadi synchro by to pravděpodobně vyřešilo.

[Karry]

To si pletes s Nepomukem. Akonadi spravuje PIM informace (kontakty, kalendare...). To co popisujes mozne je. Digikam umi zapisovat snad veskere metainformace do exif, primo do fotek. Pri kopirovani je pak umi vycist. Sam takhle provozuji dva stroje...

Nevim ale jestli je to defaultni nastaveni...

[kavol]

To si pletes s Nepomukem.

sakryš, zase byl někdo rychlejší

Digikam umi zapisovat snad veskere metainformace do exif, primo do fotek. Pri kopirovani je pak umi vycist. Sam takhle provozuji dva stroje...

to je IMO nejlepší řešení (tedy, mně by se ještě o trošinku lépe jevilo, kdyby se nemodifiovaly přímo fotky, ale ty informace byly uloženy u nich, aby se jednoduše dal zkopírovat celý adresář včetně informací, ale neznám takovéto řešení, které by bylo dostatečně přenositelné :-/ )

[stativ]

to je IMO nejlepší řešení (tedy, mně by se ještě o trošinku lépe jevilo, kdyby se nemodifiovaly přímo fotky, ale ty informace byly uloženy u nich, aby se jednoduše dal zkopírovat celý adresář včetně informací, ale neznám takovéto řešení, které by bylo dostatečně přenositelné :-/ )

Konkrétně u Digikamu tohle nastavit jde. Data se pak ukládají do XMP souboru (je tam na to hned několik nastavení).

[lertimir]

Aha, tak to díky. No přiznám se, že jsem se nikdy neodvážil cokoliv zapsat do originálních RAWů. A raději bych to měl tak, že originály (i když by to byly možná jpegy, tak bych je raději nechal nedotčené. Tak jak je zapsal foťák. A metainformace měl vedle. Samozřejmě do upravených fotek to píšu.

[Nicky726]

Modifikace metadat v RAWech je AFAIK zatím experimentální, takže tam je lepší použít zápis do extra souboru. Jinak to využívám dlouhodobě. A radši teda metadata v souborech, aby se zachovola, pokud se soubory někam přesunou.

[lertimir]

Pro mne hlavní nedostatek u digikamu je, že nemá zpracovaný efektivní workflow pro fotografa, a také, že s každou fotkou pracuje v podstatě samostatně jako s entitou a nerozlišuje primární data a odvozeniny. Prostě ty programy by primární data nikdy neměly modifikovat. Vše dělat buď tak jako Lightroom, že odvozeniny jsou jen sada parametrů, které se z primární fotky vždy znovu napočítají výslednou odvozeninu, nebo když odvozené fotky má uloženy, tak mít jasnou grafovou strukturu, která fotka ze které vznikla a jakou operací. Ke každému zdrojovému snímku mít stromeček odvozenin. A tohle mít v databázi nad celou kolekcí.

Metadata v souborech jsou fajn jen pro cílové fotky, které zpracovávající prostředí opouští. Už to, že u odvozené fotky nemám informaci, z jaké zdrojové fotky a jakou operací jsem ji získal, způsobuje, že třeba po čase tuto operaci nemohu modifikovat. Mohu jen začít se stejné zdrojové fotky a pracně hledat jakou operací jsem cíl dosáhl, nebo začít z modifikované a tu nějak měnit, ale to typicky ztratím informaci. Protože začínám na 8bitovém jpegu a ne 14 bitovém RAWu.

Ale tohle je už dost daleko od tématu vlákna.

[mck182]

DigiKam tuhle featuru uz nejakou dobu ma. Neuklada teda jenom parametry, ale cele "meziobrazky", hlavne proto, ze kdyby se to melo pokazde znova propocitavat, asi by to s aktualni architekturou kodu dost trvalo.

Kazdopadne, zakladni obrazek uz od verze 2 zustava nedotceny, vzdy se pri upravach vytvari nova verze, pricemz je mozne editovat kteroukoliv verzi a z ni zacit novou "vetev". UI dokonce ukazuje onu vetev vcetne pouzitych nastroju (mam dojem, ze se nekde ukladaji i pouzite parametry, ale to se mozna pletu), viz screenshot.

[kavol]

ee, pleteš si asi Akonadi a Nepomuk

[pc0]

Ani se mu nedivim. Oba bazmeky slouzi k ukladani metadat a pro me ne uplne pochopitelne nejsou sjednoceny v obecnou technologii.
Btw. plytvat energii na necem, co je uz v zakladu spatne je tak trochu neproduktivni.