diff options
author | Mattias Andrée <maandree@operamail.com> | 2015-08-23 05:34:08 +0200 |
---|---|---|
committer | Mattias Andrée <maandree@operamail.com> | 2015-08-23 05:34:08 +0200 |
commit | 29089ac182e0a1c3b72c2f592c7958e71d63f200 (patch) | |
tree | 509f797001e5fc0aed49060e3d11078add24a489 /doc/info/mds.texinfo | |
parent | m style (diff) | |
download | mds-29089ac182e0a1c3b72c2f592c7958e71d63f200.tar.gz mds-29089ac182e0a1c3b72c2f592c7958e71d63f200.tar.bz2 mds-29089ac182e0a1c3b72c2f592c7958e71d63f200.tar.xz |
info: features
Signed-off-by: Mattias Andrée <maandree@operamail.com>
Diffstat (limited to '')
-rw-r--r-- | doc/info/mds.texinfo | 84 |
1 files changed, 78 insertions, 6 deletions
diff --git a/doc/info/mds.texinfo b/doc/info/mds.texinfo index bb4de5b..87655f1 100644 --- a/doc/info/mds.texinfo +++ b/doc/info/mds.texinfo @@ -276,6 +276,7 @@ libraries and concepts. @menu * Overview:: Brief overview of @command{mds}. +* Features:: Reasons to install and use @command{mds}. * Architecture:: Architectural overview of @command{mds}. * Application Design:: Guildlines for your applications. * Protocol:: The @command{mds} procotol. @@ -318,7 +319,7 @@ implementation of said protocol. What makes @command{mds} stand out is its core design choice: it is designed just like a microkernel. Rather than one, possibly modular, process --- a monolithic -process --- @code{mds} is comprised of many small +process --- @command{mds} is comprised of many small servers, each exchangable and responsible for one thing. @@ -382,6 +383,77 @@ display server at risk of crashing. +@node Features +@chapter Features + +@command{mds} is not the most shiny display server +known to the planet (yet), but it does have a number +of enticing features: + +@table @asis +@item it is free software +Anybody can use, modify, and redistribute it under the +terms of the GNU General Public License version 3 +(@pxref{GNU General Public License}). Unlike some +other display server that are licnes under the MIT +license, @command{mds} is licensed under a copyleft +license. Not only that, it is a strong copyleft license +too. + +@item is is open source +As an unintended side-effect of @command{mds} being +licensed udner the GNU General Public License, +@command{mds} is also open source. The principal author +of @command{mds} do not value open source, however some +people do. + +@item it will compatible +@command{mds}'s design makes it easy to make it +compatile with any display server using a compatibility +server. When @command{mds} matures, compatibility +servers for X, Wayland and Mir will we written, both +for using those display server's client programs in +@command{mds} and @command{mds} client programs in those +display servers. + +@item it is built to survive +Unlike other dispaly servers, @command{mds} has an +object-oriented structure that allows it to evolve +without compromising its design. This structure will +help the @command{mds} undergo major redesign and +modifications without having to be entirely rewritten. + +@item it is scalable +@command{mds}'s design makes it inherently aggressively +multithreaded and easy to strip down on features, so +that it runs efficiently on any system. @command{mds} +can also be distributed on multiple computers in a +network, although the servers for this has not yet been +implemented. + +@item it is extensible +@command{mds} is designed to modified and extended. +Every part of @command{mds} is separated into distinct +servers that can easily be modified or replaced, but it +is also easy to create servers to modifies or otherwise +uses the communication between other servers and clients. +@command{mds} is a perfect place for developing new +display server technology or just learn about display +server technology. + +@item it is stable +It is possible to develop and test new @command{mds} +servers without restarting the display server. Servers +can be updated to newer versions of themself without +losing their state. This means to you never have to +restart your display server to update it. Additionally +servers that crash can be startared automatically and +their state can for the most part be restored. +@end table + + + + @node Architecture @chapter Architecture @@ -13874,7 +13946,7 @@ any other program. @cpindex Compatibility layers @vrindex @env{PREFERRED_DISPLAY} The environment variable @env{PREFERRED_DISPLAY}, -should be set with the value @code{mds}, if and only +should be set with the value @command{mds}, if and only if @command{mds} is started as a display server and not as a compatibility layer. @@ -13883,7 +13955,7 @@ list of supported display server protocol, ordered by preference. If @command{mds} is started as a compatibility layer, -@code{mds} should be added to @env{PREFERRED_DISPLAY} +@command{mds} should be added to @env{PREFERRED_DISPLAY} if and only if @env{PREFERRED_DISPLAY} lists any other display protocol. @@ -14120,11 +14192,11 @@ when starting the display server, it becomes much easier to mount the display server on top of an already running display server. For example, if you want the performance of @code{weston} but then -flexibility and functionallity of @code{mds}, you -could start @code{mds} inside @code{weston} and +flexibility and functionallity of @command{mds}, you +could start @command{mds} inside @code{weston} and replace a small set of the servers with variants written to running on top of Wayland; of course with -some functionallity of @code{mds} missing. +some functionallity of @command{mds} missing. @item @cpindex Security |