Celkem vazna odpoved

22.8.2006 09:27 | Přečteno: 1359× | poslední úprava: 22.8.2006 10:34

Uvod

V tomto postu, pozde ale preci, zminim (imho hezkou) teoretickou odpoved na otazku integrace kontaktu, konfiguraku apod.

Sdileni kontaktu, konfigace apod.

Misto slozitych serveru nad dbus by imho stacilo definovat soubory/adresare v home, napriklad ~/.shortcuts[/typ_aplikace] ~/.contacts ~/.window_manager ~/.web_browser. Napriklad kazdy web browser by si nacetl svoje nastaveni(posilani referer,cookies,....) z tohoto souboru. K tomu by se pro nastaveni on-the-fly pouzivaly standardizovane zpravy dbus(nebyla by zprava kontakt-new_contact, evolution-new_contact, ale pouze zprava new_contact). Nad tim by byla napsana knihovna, ktera by se pouzila napriklad takto:

from universal_desktop import shortcuts
# ziskani klav. zkratky
sc_play=shortcuts.get(shortcuts.PLAY)
# obdobne by se nastavilo poslouchani pro zmenu klav. zkratky on-the-fly
# zmena klav. zkratky (poslani dbus zpravy+zmena souboru)
shortcuts.set(sc_play)

realne by to muselo byt samozrejmne trosku slozitejsi (napriklad kategorie klav. zkratky). Obobne by to fungovalo pro kontakty. (Sdileni urciteho konfigu mezi ruznymy aplikacemi, a jineho mezi jinymy aplikacemi by se nastavilo tak, ze jedny aplikace by pouzivaly ~/.contacts a jine ~/.contacts-lalala.)

Sdileni mezi stroji by se zaridilo pres sdileny home

Kparts,bonobo a obdoby

Resit kparts sdilene mezi ruznymi prostredimi je imho zbytecne.

Standardni IPC

Jak uz jsem napsal vyse, toto by bylo hezci vyresit misto ruznych serveru pouze tak, ze by se zpravy standardizovaly a neposilalo se napr. [g|k]-mail_received, ale mail_received.

       

Komentáře

[VícNežNic]

Opět jsem mezitím stačil dělat nesmysly a zalíbila se mi další hračka, totiž Avahi se svým DNS service discovery. To sice nemusí být přesně to co bychom měli použít, ale insipirace je to hezká. Již podle názvu to používá DNS (hlavně SRV a TXT záznamy) takže by to asi nebylo nijak extra použitelné pro ne-IP služby.

Tady bude ale asi rozdíl v tom, že chceme od každého typu jenom jednu službu (mail, kontakty…). Můj názor je, že nejlépe by to právě bylo vyřešeno, kdybychom měli nějaký server, který nám řekne, že maily jsou dostupné tímto a tímto způsobem a zajistí, že opravdu jsou (něco jako initd kombinovaný s tím vyhledáváním služeb). Pak je samozřejmé, že od každé dílčí aplikace bude nejlépe dostávat data stejným způsobem. Ovšem pokud už na to něco existuje, proč to (v tom konkrétním případě) nevyužít? Ale to už jsem jistě psal.

[lefti]

Chtel jsem nastinit, ze pokud se standardizuji datove(kontakty,maily,...) a konfiguracni soubory. A taky zpravy posilane pres dbus (konkretni udalost se nebude dat poslat vice ruznymy zpusoby), tak nic jako "nějaký server, který nám řekne, že maily jsou dostupné tímto a tímto způsobem a zajistí, že opravdu jsou (něco jako initd kombinovaný s tím vyhledáváním služeb). ", ci Josefuv "Server" nebude potreba. A integrace bude dosazeno jednoduseji, cisteji, rychleji a unixoveji . Samozrejme je tady mozna az neprekonatelny problem: potreba, aby vetsina vyvojaru tento standard dodrzovala (hlavne bude potreba prepsat stavajici aplikace).

[VícNežNic]

Já vidím velký problém v tom, že není možnost něco ,udělat`. Data jsou v souborech a s těma můžem pracovat. Jenže co ve chvíli, kdy budeme chtít, aby ty aplikace kterým data patří něco udělaly nebo budeme chtít nějakou informaci, kterou z toho nebude možné snadno získat? Buď si to musí každá aplikace naimplementovat sama (výhody mizí docela) nebo se na to budou muset udělat knihovny (mizí výhoda oddělené na úrovni kódu).

[lefti]

Jenže co ve chvíli, kdy budeme chtít, aby ty aplikace kterým data patří něco udělaly

Aplikace načte data ze souboru a bude poslouchát dbus zprávy, jestli se data nezměnily. Co s nima bude dělat už je její věc. Ale asi jsem špatně pochopil jak si to myslel.
(dle mého skromného názoru data žádné aplikaci nepatří)

nebo budeme chtít nějakou informaci, kterou z toho nebude možné snadno získat?

Tímto myslíš například aplikaci, která bude pracovat s daty, se kterýmy se nepočítalo při návrhu "standardních datových souborů"? V tom případě autoři aplikace kontaktují správce tohoto projektu a domluví se s nimi na rozšíření (které pak budou respektovat ostatní autoři aplikacích pracujících se stejnýmy daty). Hmm ... máš pravdu, toto už je celkem krkolomný .

Další problém při takto sdílených datech bych viděl v tom, že pokud nastana chyba v aplikaci, tak může způsobit ztrátu všech sdílených dat a ne jen dat, které patří té aplikaci (jak je to dnes).

[Josef Kufner]

... ci Josefuv "Server" ...

Kdyby někdo vymyslel použitelný název, zlobit se vůbec nebudu

[Josef Kufner]

Také nejde jen o data, ale i o takové věci, jako třeba když jeden program řekne "Otevři mi informace o tomhle". Kterému programu to má říct? Jak to má říct?

Fungující ukázkou budiž odkaz mailto: ve web browseru, který otevře nový mail v mailovém klientu. Ale chci universální řešení.

[lefti]

No dobre, ale tak to by se vyresilo taky pomoci standardizovani dbus zprav. Neposle to zadnemu konkretnimu programu, nybrz "do eteru"(dbusd) posle zpravu, a program kteremu se bude libit ji zpracuje.
(V nekterych pripadech by asi bylo nutno omezit, aby zpravu dostal jen jeden program (jaky?). Ale nevim, jestli toto dbus umoznuje, ci by byli vyvojari ochoti toto implementovat)

[VícNežNic]

A dojdeš zhruba k tomu, co celou dobu navrhujeme jako Server

[lefti]

V tom pripade dbus + standardizovane zpravy = Server?

[VícNežNic]

V zásadě. Plus ještě nutnost zajistit, že na ty standardizované zprávy někdo odpoví (a umožnit nastavit kdo).

[happy barney]

A teda znova objavujete RPC (corba, dcom, ...), len ta transportna vrstva je ina .
ale napad to nie je zly, postupne definovat rozhranie, napisat binding (popr wrapper aj pre gnome/kde). Dostatocne jednoduche, dostatocne modularne, nahraditelne, to by sa mozno ujalo.

[Josef Kufner]

Jen pro info, ať se tu nevymýšlí vše od začátku: http://jk.myserver.cz/wiki/Server