Lines Matching full:role
1 ## Information for new role implementers
5 In lws the "role" is the job the wsi is doing in the system, eg,
9 for an existing role. A new role is needed when you want to add support for
13 So... what's the point of implementing the protocol inside the lws role framework?
21 - tls support working equally on mbedTLS and OpenSSL and derivatives without any code in the role
33 - core multithreaded service support with usually no locking requirement on the role code
41 The code specific to that role should live in `./lib/roles/**role name**`
43 If a role is asymmetic between a client and server side, like http is, it
44 should generally be implemented as a single role.
48 All roles should add a cmake define `LWS_ROLE_**role name**` and make its build
50 as well so user builds can understand if the role is available in the lws build it is
53 If the role is disabled in cmake, nothing in its directory is built.
55 ### Role ops struct
57 The role is defined by `struct lws_role_ops` in `lib/roles/private-lib-roles.h`,
58 each role instantiates one of these and fills in the appropriate ops
60 `./lib/roles/**role name**/ops-**role_name**.c`.
62 ### Private role declarations
64 Truly private declarations for the role can go in the role directory as you like.
66 the role adds members to `struct lws` when enabled, they should be in the role
69 Search for "bring in role private declarations" in `./lib/roles/private-lib-roles.h
70 and add your private role file there following the style used for the other roles,
81 If the role is disabled at cmake, nothing from its private.h should be used anywhere.
83 ### Integrating role assets to lws
85 If your role needs special storage in lws objects, that's no problem. But to keep
88 - declare a "container struct" in your private.h for everything, eg, the ws role wants
99 …- add your role content in one place in the lws struct, protected by `#if defined(LWS_ROLE_**role …
117 a pointer to your new role's ops struct, following the style already there.
127 This makes lws aware that your role exists, and it can auto-generate some things like
128 ALPN lists, and call your role ops callbacks for things like hooking vhost creation.
130 ### Enabling role adoption
132 The primary way wsi get bound to a specific role is via the lws adoption api
135 to bind a wsi with suitable flags to your role ops.
137 ### Implementation of the role
139 After that plumbing-in is completed, the role ops you declare are "live" on a wsi
144 - the wsi holds a pointer member `role_ops` that indicates which role ops the
147 - the wsi holds a generic uint32 `wsistate` that contains role flags and wsi state
149 - role flags are provided (LWSIFR_CLIENT, LWSIFR_SERVER) to differentiate between
159 - You set the initial binding, role flags and state using `lws_role_transition()`. Afterwards