From 6230e187fdbf9b7ea6fe6f2ca0461b6de29262cb Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 22 Aug 2024 12:12:20 +1000 Subject: [PATCH] README: reword the blurb about short lived applications This particular wording dates to when libei created devices and the EIS implementation would ack/nack those devices. This isn't the case anymore so let's reword this a bit. Closes #62 --- README.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 723d482..52c31f4 100644 --- a/README.md +++ b/README.md @@ -319,19 +319,19 @@ like `xdotool`. It provides context and device negotiation between the server and the client - the latter must be able to adjust to limitations the server imposes. -The current implemtation of the protocol does not allow for a `libei` client -to send all requests in bulk and exit. The decision on whether to accept a -device is ultimately made by the caller implementation and -non-deterministic. For **libei** to support a batch request, *someone* would -have to wait. It cannot be the server as the exact requirements are unknown: do -we pause processing on the client altogether? We may miss a disconnect -event? Do we pause processing for one device only? But then we may be -re-ordering input events and cause havoc. +The current implementation of the protocol does not allow for a `libei` client +to connect, send all requests in bulk and exit. The decision on which devices +are available is made by the EIS implementation and that requires the `libei` +client to wait until such devices are available. On a technical level the +protocol is object-oriented and requests cannot be sent until the respective +device object is available. -It could be `libei` itself to implement these event queues but this too can -mess with the input order. And implementing an event queue is not hard, so -this issue is punted to the caller instead. Xwayland in its current -implementation already does this. +The duration until devices become available is non-deterministic, and so is +what types of devices are available to a client. For **libei** to support a +connect-send-exit approach, it would still require the client process to stay +alive until device negotiation is complete within libei and all events have +been sent. And since the client process must stay alive, we might as well +have the device negotiation handled in the caller. ### uinput vs libei