Idea

18.5.2006 13:03 | Přečteno: 1863× | poslední úprava: 18.5.2006 13:15

Dnes mi Jindra Plešinger připomněl svým blogpostem o kontrole pravopisu moji dlouhodobou myšlenku.

Používám prostředí KDE a líbí se mi, že se snaží vše provázat. O co se jedná? Jednotný systém kontaktů, který využívá KMail i kopette (to mám z druhé ruky, sám používám PSI). Kparts (např. textový editor Kate v okně zcela jiného programu, nebo kpdf v okně prohlížeče webu), beru skoro jako samozřejmost. Ještě to není dokonalé, snad v dalších versích.

Co takhle jít dál? V KMymoney mám seznam plátců, který není synchronizovaný s kontakty. Nebylo by hezké se mrknout na plátce, kterým vám dluží, rovnou z KMymoney mu napsat email, nebo poslat IM zprávu? Kolekci amaroKu mám v MySQL databasi. Tak proč ne všechny emaily, kontakty, historii IM komunikace a třeba i správu versí dokumentů? Tohle všechno využívám, jen odděleně. Subversion támhle, db kontaktů interní KDE, emaily v mail diru (a je požitek jich mít 100 000*) a historie PSI je ve vlastním formátu, který sice jde "snadno" rozparsovat, ale to se dá říct prakticky o všem.

Pokusil jsem se něco takového navrhnout sám (v freemindu je to pěkná mapa), ale je to nad mé síly. Chci se zeptat, neexistuje něco takového? Prosím, odkazy na MS Office si nechte, hledám něco FOSS a ani ty office to nemají dotažené do konce.

Celé by to bylo postavené na otevřených formátech, o data by se starala volitelná SQL database (snad není takový problém zajistit obecnou kompatibilitu na úrovni SQL příkazů). To znamená, že by nebyl problém se připojit přes šifrovanou linku odkudkoliv a mít tak svá data neustále při sobě.

*) Dávat to sem je trochu OT, ale nechci zakládat další blog. To opravdu neexistuje klient nebo systém, který by to zvládl? Pro MS Outlook (a prosím, nechci flame), nebyl problém mít 30 000 emailů v jedné složce. Outlook používal vlastní DB emailů a podle mého názoru, to dělal dobře. Na linuxu jsem našel jen mailbox (hmm 3GB textový soubor, co takhle smazat 15 emailů na začátku?), maildir nebo mb (co email, to soubor -- čímž se problém přesouvá na filesystém a nenašel jsem takový, který by to rozumně zvládal). Jak tohle řeší seznam, gmail a podobní? Vždyť ti se musejí postarat o miliardy emailů.

       

Anketa

Komentáře

[Michal Čihař]

IMHO evolution-data-server se přesně o toto snaží .

[White Raven]

No, nad niečím podobným som už tiež istý čas uvažoval. Žiaľ, stále ostávam pri tom "chcel by som..." Jednoducho neexistuje nič, čo by mi úplne vyhovovalo.

Btw - nie je jeden z "propagačných bodov" Linuxu aj to, že máme slobodu voľby? V takom prípade môžeme o integrovanom systéme len snívať ;)

[Heron]

Ale ten systém by nemusel být vůbec integrovaný. Mám pocit, že tohle UNIXovskou myšlenku nepopírá ale naopak podporuje.

O co se jedná: uprostřed bude server (volitelný) a na něj se připojovali klienti (různí) a ti by jen dodržovali protokol.

Prostě program na správu financí (libovolný), by si ze serveru vyžádal svoje data (tedy včetně seznamu kontaktů, které by považoval za plátce). Tento seznam kontaktů by spravoval opět libovolný program na kontakty. V tom finančním programu bych si chtěl poslat email a o to by se postaral opět volitelný klient, který jen dodržuje stanovený protokol, a od finančního programu dostane kontakt, na který to má poslat.

Tj. každý uživatel by měl své oblíbené programy a mohlo by to mít i webové rozhraní. Já v tom opravdu takový problém nevidím (je to kupa práce, to je fakt, ale nic co by nebylo vyřešené).

[JiK]

Pekny koncept. Jako bych ho odnekud znal, cele by to mohlo byt fulltextove prohledavatelne nejakym desktop searchem. Neco jako Spotlight. Mozna je rychlejsi a jednodussi si koupit si Mac OS X?

[Josef Kufner]

To jsem rád, že nejsem sám, kdo má takovouhle pedstavu. Začínám celkem vážně uvažovat o tom, že bych si to dal jako bakalářku nebo diplomku (pokud se ve škole do té doby udržím).

Myslím, že by stačilo napsat ten server, knihovnu pro klienta a demonstrativně to implementovat v pár programech. Podmínkou ale je, že te nebude vázané na žádný desktop, ani nic jiného. Server by mohl mít i několik rozhraní, aby byl schopný komunikovat přes dcop (kde) a nějaký ten gconfd, corba nebo co to v gnome je. To by asi bylo vhodné udělat obdobně jako transporty v jabberu, ale nechal bych to na později, pokud vůbec. (Spíš aby se s tím trošku počítalo v návrhu.)

Zatím největší problém vidím v tom, že nejsou kvalitní nenáročné standalone programy, které by se daly lehce pospojovávat. Je tu pár bumbrdlíčků, ale jinak celkem bída.

Co se týče ukládání dat, tak to bych nehrotil. Každý program má trošku jiné požadavky a kadý existující tohle už má vyřešené. Mám představu takovou, že by tenhle systém byl opravdu jen a jen pro propojení programů. Uživatel by si určil který programy bude používat. Každý program by řekl co umí, jaká data obhospodařuje a další programy by se pak ptaly serveru, že chtejí to i ono a server by požadavek předal programu, který je k tomu určen. Například psi by chtělo seznam kontaktů, tak by si řeklo serveru. Server má nastaveno, že na správu kontaktů se používá program kab (tuším ta věc v kontactu) a předá jí požadavek. Kab si vytáhne ze svých dat seznam kontaktů a předá ho serveru a ten ho předá psi. Má to však jeden háček: Oba programy musí být spuštěné, ale to by se dalo obejít hned několika způsoby a v některých případech by to ani nevadilo.

Pak je ještě možnost, že by sklad dat byl jedním s klientů. Například evolution-dataserver. Ale zda by ho něco používalo je věc druhá.

Tak jako tak je tu hodně místa k vymýšlení.

[Heron]

Dobrý připomínky. Chce to pořádně promyslet.

Mno, já už mám bakalkářku takřka hotovou a týká se fyziky (a případná dimplomka nebude moc jiná). Ale kdyby jsi to přece jen chtěl psát, tak se ozvi (jak jsem psal v blogu, mám pár poznámek ve freemindu).

[Eregon]

Dost se mi to líbí, jedna z dalších výhod, které by to vcelku určitě mělo, by byla možnost vyměnit kterýkoli z obslužných programů bez nějakých komplikovaných konverzí dat a podobně.

Napadá mě ale otázka - jaké typy dat bude obhospodařovat server? Můžeme říct, že potřebujeme maily, kontakty a třeba historii IM, k tomu třeba ty finanční záznamy.

Někdo další ale může mít další potřebu. Dejme tomu, že používám VoIP, hovory si nahrávám a chci svého klienta na tento server napojit, abych měl nahrávky provázané s kontakty atp.

S podobnými dalšími potřebami může přijít kdykoli kdokoli - je tedy potřeba, aby server nebyl v principu omezen typem dat a bylo na něj možné ukládat relativně cokoli, aniž by to řešil. Pokud by to náhodou řešit musel (přesněji, pokud by byly potřeba specifika v komunikačním protokolu), mělo by to být řešitelné např. doplněním nějakéhu pluginu.

[Heron]

Díky.

uff, mám to psát do TO-DO?

[Josef Kufner]

Zitra (teda spis dneska) nahodim wiki na svem webu a hodim tam nejaky zaklad... bude prostor pro vymysleni a diskutoval bych i nadale zde, at se k tomu muze vyjadrit co nejvice lidi.

[Heron]

Ok, to bude perfektní. Já wiki mám, ale omezené jen na sebe (jsou to moje osobní webky). Takže je uvolnit pro editaci nemůžu.

[Josef Kufner]

Tak tady je ta wiki: http://jk.myserver.cz/wiki/Server

Pište a tvořte dle libosti

[Milan Horák]

Tak jsem začal ...

[Heron]

Založil jsem si tam účet.

[Josef Kufner]

Server by měl být co nejjednodušší. Já bych tam nějaké ukládání dat necpal. Myslím, že by stačilo, aby server zprostředkovával jen spojení mezi klienty a nic víc. Držel by si akorát informace o tom který klient co umí a co si uživatel vybral používat, ale víc ani ťuk. Veškeré skladování dat bych nechal na klientech. Buď by si to mohl držet přímo program, který by to používal. Nebo by byl specializovaný klient, který by sloužil jen jako skladiště dat určitého typu. Vedlo by to k opravdové modularitě, kde by se dal nahradit mbox za imap, aniž by si toho mail klient všimnul.

[Heron]

Hmm, jak na to potom chcete přistupovat přes web?

Máte webového klienta, ten se připojí na server, který (podle vašeho nápadu), jen zprostředkuje komunikaci mezi programy. Takže vám běží web, server (ten běží pořád) a ještě 6 dalších klientů pro různý věci.

Já se této myšlence nebráním, ale nelíbí se mi. Místo toho bych chtěl, aby všechna data spravoval server -- klidně modulární, bude snadné přidat modul pro "třeba poznámky", server si je uloží do své DB (to už je detail) a pak k tomu můžou přistupovat poznámkový klienti.

[Heron]

Rozumíte, když bude hlídat data server, můžu si emaily přečíst jak na webu, tak v grafice a klidně i na terminálu (použil jsem tři různý klienty, kteří pracovali nad stejnýma datama). Kdyby si data hlídal klient, tak tohle udělat nemůžu.

[Josef Kufner]

To jo, ale pokud data může hlídat klient, tak to nevyžaduje tolik zásahů do existujících programů a ty programy budou použitelné i bez serveru.

[devon]

Jak tu tu sleduji, tak se mi tahle myšlenka stále honí hlavou, přispěji tedy také svou troškou myšlenek. Nějaká db na netu, případně aplikace ji obhospodařující, je asi nezbytná, ale z důvodu offline bude asi stejně potřeba, aby si data spravovala aplikace sama a do db se data pouze replikovala. Co to tedy udělat nějak takto:

1. Klientská aplikace (démon), do které se nainstalují pluginy pro konkrétní programy (im, mail, atp.), s možností spouštět jako samostatný program s parametry.

2a. Spousta existujících aplikací umožňuje spustit nějaký program při nějaké akci (třeba příchod mailu). Spustí tedy daný plugin a předá parametry specifikující co je to za akci.

2b. Pokud není možné předchozí a existuje jednoduchý způsob, jak k dané aplikaci plugin udělat, tak udělat.

2c. Pokud předchozí nebude snadno zrealizovatelné, tak démon na základě pluginu bude v definovaném intervalu zkoušet sám zjistit změny v aplikaci (třeba změna v logu im, přečte změnu a provede kýžené)

3. Démon už ví, že se něco změnilo, projde nastavení, jestli na danou změnu má něco udělat

4. Vykoná zvolené (spustí mail klient s parametry - o to se postara plugin pro daného klienta)

5. Vše se pokouší replikovat na server

Pokud třeba nebudu mít doma nainstalovaný program, odpovídající nějaké akci, tak na server uloží status o nevykonané akci. Když pak přijdu do kanceláře, démon zjistí neprovedenou akci, ověří že on pro danou akci program (plugin) má, tak akci provede nyní.Úmyslně teď neřeším pracovní skupiny a sdílení dat. Data na serveru by mohla být pro jednotlivé programy ukládána v xml, to by mohlo být snad dostatečně univerzální. Konfigurace by se taktéž replikovala na server, ale s rozlišením různých pracovišť s informací o pluginech a klientech na nich.

Co by tedy bylo potřeba:

1. Definovat strukturu DB

2. Framework pro webovou aplikaci - s jasně definovaným API pro pluginy

3. Základ webové aplikace pro nastavování

4. Základní pluginy na webu pro mail, im, kalendář (včetně rozlišení nejpoužívanějších aplikací

5. Klientský démon a pluginy pro něj s jednoduchým návodem k danému programu

Každý program by tedy potřeboval plugin pro démona, plugin do sebe nebo specifikaci jako propojit s démonem, specifikaci xml do db, plugin na web pro konfiguraci akci atp.

Jo a hlavně pořádnou analýzu a hodně času

Uff, jsem se rozepsal.... mno prostě pár myšlenek

[Heron]

Pěkný.

Jen si asi nerozumíme v jedné věci. Pod pojmem server mám na mysli daemona, tedy službu běžící na Vašem desktopu a nikoliv server jako samostatný stroj. Pochopitelně, na tohoto daemona se bude moci dát připojit i z Internetu, pokud to uživatel potřebuje.

[devon]

Mno já bych to právě dělil. Na každém pracovišti by byl ten démon, co by sledoval změny v programech, spouštěl požadované akce, replikoval změny do db na netu a samozřejmě zpět.

[devon]

Ještě mě napadlo, ten server na netu bude vlastně takové překladiště. Něco jako imap. Prostě doma mam IM, který si zapisuje do logu. V práci mám stejný im (taky zapisuje do logu). Pak ale něco hledám v práci a zjišťuji, že to mám v logu doma. Takže ten démon by přečetl změnu v logu, přenesl ji na server, doma by zase démon přečetl změnu ze serveru a zanesl ji do logu doma. Prostě konec bordelu v tom, kde jsou jaká data.

[Heron]

Hmm, ale tohle mi už něco připomíná. Takovej systém (i když ne obecně) jsem už někde viděl. Kurnik, chce to zlepšit paměť.

[Josef Kufner]

Ono tyhle dva přístupy nejsou tak odlišné, jak se na první pohled možná zdá. Pokud se budou používat moduly, tak to znamená další API a další zesložitění serveru. Pokud to budou jako normální klienti, tak budou používat stejné API jako všechno ostatní, ale přitom to může být stejně nenáročné jako kdyby to byl modul.

Zásadní podmínka pro tohle, ale i celkovou funkčnost je to, že bude možné spouštět jednotlivé klienty na vyžádání. S tím, že ten klient nemusí nastartovat celý, ale jen jeho část, kterou je zrovna potřeba. Tím se vyřeší i množství klientů, kteří musí běžet nonstop. Prostě nepoběží a spustí se, až budou potřeba.

Taky těch klientů nemusí být nijak mnoho. Může být klient, který se spojí s SQL databází a bude se tvářit, že umí ukládat jak poznámky, tak historii z IM. Takový klient by v paměti zabíral pár set kilo a naprostou většinu času visel v selectu (nebo něčem jiném). Pokud by takový klient nebyl potřeba, tak by se klidně mohl po nějakém čase nepoužívání ukončit (nebo taky ne).

[Luboš Doležel (Doli)]

V AmaroKu taky používám MySQL (ačkoliv betaverze 1.4 měly podporu MySQL trochu nepříjemně/zvláštně zabugovanou), ale aby to bylo složitější, tak na poštu používám Evolution.

Na IM používám taky Psi. Propojení mi schází...

Peníze mi nikdo nedluží

[Heron]

Evolution zkusím, včetně toho data-center.

Peníze mi nikdo nedluží

To přijde, neboj

[Vlastimil Ott]

Kdybyste jednou potřebovali dokumentaci, rád se na ní budu podílet.

[hydrandt]

Ten umí to a ten zas tohle...

[Vlastimil Ott]

Však my ten kapitalismus nakonec nějak vybudujeme...

BTW, proč my dva jsme ještě nešli na pivo a nezaložili nějaký LUG?

[hydrandt]

Na pivo někdy zajít klidně můžem, i nějaký ten LUG klidně založit Jenom jsem trochu mladší, ve škole bych ti vykal a říkal "pane profesore"...

Vím, že tu jsou ještě asi další dva lidi z Opavy, tak se můžeme někdy domluvit a jít si někam sednout..

BTW, za chvilku se chystám do Evžena, náhodou tam nebudeš, že?

[Vlastimil Ott]

říkal "pane profesore"...

Hehe. Já ale nejsem zas tak starý.

tak se můžeme někdy domluvit a jít si někam sednout.

Jsem pro.

BTW, za chvilku se chystám do Evžena, náhodou tam nebudeš, že?

No, dneska ne, ale nejsem proti. Teď ale nevím, kde to je...

[hydrandt]

Starý nejsi, ale to nic nemění na tom, že jsem o dost mladší

Evžen je..po Ostrožné nahoru a doprava Něco jako pokus o web mají tady. Alespoň je tam program...

[Daniel Kvasnička ml.]

Vím, že tu jsou ještě asi další dva lidi z Opavy, tak se můžeme někdy domluvit a jít si někam sednout..

To muzem V srpnu se do Opavy stehuju na tvrdo...

[Heron]

No ale, mi já to nechci psát, pokud to už existuje. Jak se ale zdá, tak ne. Byl to jen návrh. Pokud z něj vzejde projekt (který bude z 80% odsouzený k neůspěchu, což je normální), tak to bude jen dobře.

Btw: proč nejedeš na LVB?

[Vlastimil Ott]

Obávám se, že vrcholem použitelnosti je KOrganizer. Což je celkem fajn, ale je tam spousta věcí, které lze přece tak snadno "dodělat". Je fakt, že nemám poslední verzi...

LVB> Nějak se mi nechce, ale především nemám kde spát. A na ponocování jsem starý a líný. A rozhodně bych jel autem, odmítám ponocovat v nočním vlaku na Ukrajinu nebo do Polska... ;)

[Heron]

Nějak se mi nechce, ale především nemám kde spát. A na ponocování jsem starý a líný. A rozhodně bych jel autem, odmítám ponocovat v nočním vlaku na Ukrajinu nebo do Polska

Rozumím. No já mám slíbený nocleh od teroristy, ale jak to dopadne ... to nikdo neví.

[XXX]

čus. chrapat mužeš u mě. Teda jestli tam nebude plno... ) LOL. Ne fakt. Noclehc je zajištěnej...

[Josef Kufner]

A proto to musí být naprosto dokonalé, unikátní a musí se to všem líbit, aby se to vešlo do těch 20 %