Portál AbcLinuxu, 30. dubna 2025 12:43

Nástroje: Začni sledovat (0) ?Zašle upozornění na váš email při vložení nového komentáře.

Vložit další komentář
22.8.2006 10:42 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
Odpovědět | Sbalit | Link | Blokovat | Admin
:-)

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.
Copak toho není dost?
22.8.2006 14:03 lefti | skóre: 18 | blog: OneAndOnlyTrueBlog
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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).
22.8.2006 14:12 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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).
Copak toho není dost?
22.8.2006 16:52 lefti | skóre: 18 | blog: OneAndOnlyTrueBlog
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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 avatar 22.8.2006 15:37 Josef Kufner | skóre: 70
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
... ci Josefuv "Server" ...
Kdyby někdo vymyslel použitelný název, zlobit se vůbec nebudu ;-)
Hello world ! Segmentation fault (core dumped)
Josef Kufner avatar 22.8.2006 15:42 Josef Kufner | skóre: 70
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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í.
Hello world ! Segmentation fault (core dumped)
22.8.2006 16:34 lefti | skóre: 18 | blog: OneAndOnlyTrueBlog
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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)
22.8.2006 16:39 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
A dojdeš zhruba k tomu, co celou dobu navrhujeme jako Server ;-)
Copak toho není dost?
22.8.2006 16:58 lefti | skóre: 18 | blog: OneAndOnlyTrueBlog
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
V tom pripade dbus + standardizovane zpravy = Server?
22.8.2006 17:02 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
V zásadě. Plus ještě nutnost zajistit, že na ty standardizované zprávy někdo odpoví (a umožnit nastavit kdo).
Copak toho není dost?
23.8.2006 07:50 happy barney | skóre: 34 | blog: dont_worry_be_happy
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
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 avatar 22.8.2006 10:47 Josef Kufner | skóre: 70
Rozbalit Rozbalit vše Re: Celkem vazna odpoved
Odpovědět | Sbalit | Link | Blokovat | Admin
Jen pro info, ať se tu nevymýšlí vše od začátku: http://jk.myserver.cz/wiki/Server
Hello world ! Segmentation fault (core dumped)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.