Diskuse:Server
Z JKwiki
Obsah |
White Raven: Ja teraz neviem...
Ja teraz neviem, či som myšlienku servera pochopil správne (resp, či sa aspoň v základe zhodujeme), tak redšej sem napíšem, čo si myslím a pls, vyveďte ma z prípadného omylu...
Server
Dátový server, v ktorom sú uložené všetky možné dáta - kontakty, e-maily, IM správy, kalendáre... Je to centrálne úložisko, ku ktorému pristupujú aplikácie cez viac-menej štandardné protokoly, ak to je možné, alebo cez nejaké nové - presne určené pre danú situáciu (IM klienti, financie).
Napríklad pri mailoch nevidím problém - IMAP. Kalendár cez WebDAV. Horšie je to s kontaktami - tam sa, tuším, používa najčastejšie trošku ťažkopádny LDAP a zatiaľ som nepozeral, či existuje niečo použiteľnejšie.
Dáta
Dáta uložené v DB - to je asi jasné. Snáď by mohol nastať problém kvôli rôznorodosti aplikácií - napríklad export kontaktov do vCard z Evolution sa nezhoduje s exportom z KAddressBook a podobne. Sú to ale len malé odlišnosti, tak hádam je to prekusnuteľné.
A relačná databáza už sama o sebe prináša niekoľko možností optimalizácie uskladnenia údajov.
Aplikácie a komunikácia so serverom
Ako som už spomenul, aplikácie by k serveru pristupovali pomocou rôznych protokolov. Prekážkou môže byť to, že zdaleka nie každá aplikácia vie komunikovať prostredníctvom všetkých protokolov (a prienik komunikačných možností všetkých aplikácií bude zaručene prázdnou množinou).
Treba na každý účel dôkladne vybrať jeden alebo dva protokoly, s ktorými bude server vedieť narábať.
-- White Raven 15:07, 22. 5. 2006 (CEST)
- Spíše bych to viděl tak, že server je prostředníkem mezi daty a aplikacemi data požadujícími.
- -- Milan Horák 15:22, 22. 5. 2006 (CEST)
- Přesně tak. Server by měl sloužit hlavně jako prostředník k výměně dat. Ukládání může obstarat nějaký klient k němu připojený.
- -- Josef Kufner 23:34, 22. 5. 2006 (CEST)
- Takže - server sa pripojí k dátam jedného klienta a sprostredkuje ich inému klientovi?
- -- White Raven 07:36, 23. 5. 2006 (CEST)
- V podstatě jo, klient, který ty data bude chtít, je musí nějak identifikovat a pokud umí komunikovat s jiným klientem, tak proč tam zanášet další složitosti... Výhodou bude, že si může vybrat z více DB.
- -- Josef Kufner 07:49, 23. 5. 2006 (CEST)
- Aha. No tak to sa mi zdá o hodný kus komplikovanejšie, ako som myslel...
- -- White Raven 07:56, 23. 5. 2006 (CEST)
- Jak se to veme. Klient bude mluvit akorat s jinýma klientama, server bude jen přehazovat data. Bude jen jedno API, jeden adresní prostor a jeden seznam aliasů. Ale pokud máš jinou představu, jak by to mohlo být, tak sem s tím :)
- -- Josef Kufner 08:03, 23. 5. 2006 (CEST)
- Tudiz, kdyz budete chtit ziskat vsechny kontakty budete muset poslat query vsem aplikacim (ktera navic v tu dobu nemusi bezet). Imho by bylo jedndodusi, kdyby data spravoval server. Moznost pouzit vic db by mohla byt resena tak pomoci flagu kazdeho zaznamu. Nevyhodu vydim v tom, ze bez beziciho Serveru nebude nic fungovat.
- --lefti 07:16 22.8. 2006
Alternativa: UNIXové řešení
(No dobře, snůška blábolů) Czest!
Takže, co je tipicky UNIXoidní způsob řešení? Samozřejmě soubory a slyšel jsem (a považuju za nesmysl), že rozhodně nemá nic společného se sokety, které mrší celý, jinak nádherný, návrh.
Tedy ideově správně by měl být celý Server kryt před klienty jakousi souborovou vrstvou. To by umožnilo řešit vybrání záznamu z databáze jako zápis identifikátoru záznamu do souboru a následné čtení z něj. Když klient soubor smaže, vyjádří tím přání smazat uložená data, s ostatními klienty bude moct komunikovat zápisem do jejich souboru (nebo do nějakého společného, ve krerém mu server vrátí odkaz na další soubor, který bude pro klient2klient komunikaci použit a tak dále.
Nemyslím si, že to oproti soketům má nějaké výhody, vlastně vím o jedné podstatné nevýhodě - nemožnosti komunikace mezi programy na různých počítačích. To by se dalo řešit jakýmsi (ala Plain9, Inferno) exportem a následným bindem souborů, což je ale obrovský kus práce navíc.
Též by se dalo uvažovat o systému, kde by klienti byli vlastně moduly serveru, který by je držel na jakémsi sandboxu, odchytával přístupy k datům a podstrkoval jim svoje. Vzdálený přístup by byl řešen komunikací dvou Serverů mezi sebou, přičemž každý by běžel na jiném počítači.
PS: Už se vidím jako spokojený užiavatel ;-) Jiří Daněk (Djura)
- "Vsechno je soubor" se tady moc nehodi. Dalo by se s pomoci fuse exportovat vse do nejakeho pseudofilesystemu, ale nevidim v tom az tak zasadni vyhody (coz neznamena, ze to nema smysl). Dulezita je vlastni komunikace mezi programy, coz je to podstatne a chybejici. Se sitovou vrstvou jsi to trefil presne :)
- -- Josef Kufner 23:52, 12. 8. 2006 (CEST)
- Takže meziprocesová komunikace?
- Co třeba zavést události. E-mailový klient odešle na Server zprávu u novém mailu a ten to přepošle všem ostatním klienům, kteří se k odběru této zprávy (tohoto okruhu zpráv) přihlásili. Stejně tak by se i žádalo o data; žádost o data dostane klient, který se přihlásil k odběru žádostí. Takto bychom mohli mít k serveru připojeno i více serveroidních klientů, kteří by poskytovali různé druhy informací; jeden kontaktlist, druhý kalendář, třetí e-maily... Tázající se by pak dostal tři odpovědi (ne přímo data, třeba u těch e-mailů je to žádoucí takto) a mohl by si stejným způsobem vyžádat data. Takže bude mít veškeré informace o třeba Františku Novákovi, které je možné na počítači/počítačích najít. Ty pak může využít k získání dalších informací. Třeba z kontaktlistu se dozví JabberID hledaného člověka a tak si stáhne i jeho VCartu.
- Mimochodem, možná by stálo za to zkusit LINUXové řešení - přesunout vývoj na jih, k tučňákům. ;-)
- -- Jiří Daněk 13:27, 13. 8. 2006 (CEST)
- Takže meziprocesová komunikace?
- Zatím to vypadá tak, že by bylo nejlepší sepsat specifikaci protokolu nad D-Bus, kde by bylo dáno jak najít ostatní klienty, jak k nim přistupovat a co by měli zpřístupňovat. Tím bude vyřešena komunikace a ukládání dat už není problém (jeden specializovaný démon). Možná to ještě zapouzdřit do nějaké knihovny s jednodušším API.
- -- Josef Kufner 14:12, 13. 8. 2006 (CEST)
- Takže vše je obecně vyřešeno? Jinak, s tím jediným datovým daemonem se mi to moc nelíbí - postupně by se z něj stal moloch. To se dá řešit modulární strukturou, ale k tomu je nutné tvořit další API. Spíš preferuji specializované datové klienty.
- To by také umožnilo aby Server zastával obdobnou roli, jako daemon inetd a tak se snížilo zatížení systému.
- Také by bylo jednodušší sdílení mezi počítači; uživatelé si mohou u jiného počítače 'bindnout' datového klienta, a to právě takového, o jehož data mají zájem.
- Navíc pokud spadne jeden datový klient, ostatní zůstanou netknuti.
- -- Jiří Daněk 21:28, 13. 8. 2006 (CEST)
- Takže vše je obecně vyřešeno? Jinak, s tím jediným datovým daemonem se mi to moc nelíbí - postupně by se z něj stal moloch. To se dá řešit modulární strukturou, ale k tomu je nutné tvořit další API. Spíš preferuji specializované datové klienty.
- No, vypadá to, že tvoje představa je celkem kompatibilní s mojí :) Co se týče datových klientů, považuji za rozumné využít stávající programy i jejich uložení dat. Prostě říct poštovnímu programu "dej mi tenhle mail?", adresáře se zeptat "kde tenhle člověk bydlí?" nebo i "ulož tohle". Takže by žádný specializovaný klient nakonec nebyl potřeba, jen udělat možnost splnit požadavek bez spouštění celého (velkého) programu. A pak onen "inetd", který by se staral o požadavky pro neběžící klienty (a spouštěl je).
- Bohužel, teď na tohle nemám čas, ale klidně upravuj, co je zde popsáno. Případně napiš i více možností. V nejhorším se dají změny vrátit ;)
- -- Josef Kufner 22:45, 13. 8. 2006 (CEST)
- "...jen udělat možnost splnit požadavek bez spouštění celého (velkého) programu."
- A to jde? Mimochodem, tohle by se lépe řešilo v síťovém OS Inferno. Tam je každý program tvořen moduly (dobře napsaný program), které jsou spustitelné i nezávisle na sobě. Vlastně celý systém je jeden modulární program interpretovaný virtuální mašinou. Chtělo by to návrat do budoucnosti :) .
- A to jde? Mimochodem, tohle by se lépe řešilo v síťovém OS Inferno. Tam je každý program tvořen moduly (dobře napsaný program), které jsou spustitelné i nezávisle na sobě. Vlastně celý systém je jeden modulární program interpretovaný virtuální mašinou. Chtělo by to návrat do budoucnosti :) .
- Do wiki se mi teď moc vrtat nechce, to se radši budu učit GTK, nebo si užívat prázdninové atmosféry. A nebo obojí.
- -- Jiří Daněk 12:53, 14. 8. 2006 (CEST)
- "...jen udělat možnost splnit požadavek bez spouštění celého (velkého) programu."
- Dalo by se programu dát option, který by řekl něco ve smyslu "Nespouštěj se celej, jen se připoj tam a tam". Takže by mohla odpadnout inicializace gui a podobně. Nebo by se udělala další binárka, která by se v případě potřeby postarala o požadavek a přitom vycházela z původního programu a byla součástí jednoho balíčku.
- -- Josef Kufner 16:42, 14. 8. 2006 (CEST)
- Ta řešení jsou si podle mě rovnocená, druhá možná o trochu lepší v tom, že se ve výsledné binárce nedublují dva rozdílné způsoby přístupu k datům - částečné spuštění a využití běžící aplikace. Navíc při částečném spuštění se do paměti stejně načte celý program (IMO, možná je to překonaná praktika nebo didaktické zjednodušení). Druhé řešení je vpodstatě můj nápad serveroidních (datových) klientů v lepším balení, a tedy hlasuji pro druhou možnost.
- -- Jiří Daněk 18:44, 14. 8. 2006 (CEST)
- Řekl bych, že to je spíš o tom, jak je který program napsán, navržen a co bude jednodušší udělat, ale jinak souhlasím :)
- -- Josef Kufner 19:04, 14. 8. 2006 (CEST)
- A ještě jedna věc. Na Rootu.cz v článku Guruův kvíz – nerozumím Linuxudesktopových zazněla jedna z postatných nevýhod Udevu, tj. že system je naprosto nepoužitelný, pokud náhodou Udev nenastartuje. Tedy pokud nenastartuje Server, budou aplikace samy o sobě taky k ničemu a to by mohl být problém. Místo udevu je možné použít příkaz mknod, ale server tak jednoduše nahradit nepůjde.
- -- Jiří Daněk 21:12, 14. 8. 2006 (CEST) 21:10, 14. 8. 2006 (CEST)
- Když nenastartuje udev, tak tam je ještě statický /dev, takže to katastrofa nejni. Tak jako tak, pokud by to katastrofa byla, tak nepoběží skoro nic.
- -- Josef Kufner 23:49, 14. 8. 2006 (CEST)
- Asi už jsem byl včera moc rozespalý :) Pokud server padne, tak aplikace budou fungovat tak jako dnes – jen si mezi sebou nebudou povídat. Problém budou mít programy, které budou používat pouze data z jiných klientů. Ale dbus mi ještě nespadl a ta obdoba inetd jde lehce restartovat.
- -- Josef Kufner 10:26, 15. 8. 2006 (CEST)
Klavesove zkratky
Ma "Server" resit i klavesove zkartky? Napriklad si nastavim globalni klavesovou zkratku v kcontrol a nastavi se mi ve vsech aplikacich v systemu.
-- 212.80.64.202 07:20, 22. 8. 2006
- Myslím, že tohle je vyřešeno celkem použitelně vrámci desktopů, takže bych to neviděl jako to nejdůležitější. Nicméně bylo by možné počítat s možností měnit konfiguraci programů (klientů) za běhu.
- -- Josef Kufner 10:36, 22. 8. 2006 (CEST)
