1*84e872a0SLloyd Pique<?xml version='1.0' encoding='utf-8' ?> 2*84e872a0SLloyd Pique<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ 3*84e872a0SLloyd Pique <!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent"> 4*84e872a0SLloyd Pique <!ENTITY doxygen SYSTEM "ServerAPI.xml"> 5*84e872a0SLloyd Pique%BOOK_ENTITIES; 6*84e872a0SLloyd Pique]> 7*84e872a0SLloyd Pique<appendix id="sect-Library-Server"> 8*84e872a0SLloyd Pique <title>Server API</title> 9*84e872a0SLloyd Pique <section><title>Introduction</title> 10*84e872a0SLloyd Pique <para> 11*84e872a0SLloyd Pique The open-source reference implementation of Wayland protocol is 12*84e872a0SLloyd Pique split in two C libraries, <link 13*84e872a0SLloyd Pique linkend="sect-Library-Client">libwayland-client</link> and 14*84e872a0SLloyd Pique libwayland-server. Their main responsibility is to handle the 15*84e872a0SLloyd Pique Inter-process communication (<emphasis>IPC</emphasis>) with each 16*84e872a0SLloyd Pique other, therefore guaranteeing the protocol objects marshaling and 17*84e872a0SLloyd Pique messages synchronization. 18*84e872a0SLloyd Pique </para> 19*84e872a0SLloyd Pique <para> 20*84e872a0SLloyd Pique The server library is designed to work much like libwayland-client, 21*84e872a0SLloyd Pique although it is considerably complicated due to the server needing 22*84e872a0SLloyd Pique to support multiple versions of the protocol. It is best to learn 23*84e872a0SLloyd Pique libwayland-client first. 24*84e872a0SLloyd Pique </para> 25*84e872a0SLloyd Pique <para> 26*84e872a0SLloyd Pique Each open socket to a client is represented by a <link 27*84e872a0SLloyd Pique linkend="Server-structwl__client">wl_client</link>. The equivalent 28*84e872a0SLloyd Pique of the <link linkend="Client-classwl__proxy">wl_proxy</link> that 29*84e872a0SLloyd Pique libwayland-client uses to represent an object is <link 30*84e872a0SLloyd Pique linkend="Server-structwl__resource">wl_resource</link> for 31*84e872a0SLloyd Pique client-created objects, and <link 32*84e872a0SLloyd Pique linkend="Server-structwl__global">wl_global</link> for objects 33*84e872a0SLloyd Pique created by the server. 34*84e872a0SLloyd Pique </para> 35*84e872a0SLloyd Pique <para> 36*84e872a0SLloyd Pique Often a server is also a client for another Wayland server, and 37*84e872a0SLloyd Pique thus must link with both libwayland-client and libwayland-server. 38*84e872a0SLloyd Pique This produces some type name conflicts (such as the <link 39*84e872a0SLloyd Pique linkend="Client-classwl__display">client wl_display</link> and 40*84e872a0SLloyd Pique <link linkend="Server-structwl__display">server wl_display</link>, 41*84e872a0SLloyd Pique but the duplicate-but-not-the-same types are opaque, and accessed 42*84e872a0SLloyd Pique only inside the correct library where it came from. Naturally that 43*84e872a0SLloyd Pique means that the program writer needs to always know if a pointer to 44*84e872a0SLloyd Pique a wl_display is for the server or client side and use the 45*84e872a0SLloyd Pique corresponding functions. 46*84e872a0SLloyd Pique </para> 47*84e872a0SLloyd Pique </section> 48*84e872a0SLloyd Pique &doxygen; 49*84e872a0SLloyd Pique</appendix> 50