README: update the blurb about batched processing

Short story, we can't do it but it's simple enough to work around in the
caller so let them do it.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

README.md

@@ -203,12 +203,21 @@ the compositor instead.
 
 ### Short-lived applications
 
-**libei** is not primarily designed for short-lived fire-and-forget-type
-applications like `xdotool`. It provides context negotiation between the
+**libei** is not designed for short-lived fire-and-forget-type applications
+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 however allows for a `libei` client
-to send all requests in bulk and exit. Data is however processed in-sequence
-by the `libeis` server so where the connection and device creation is
-accepted by the server as-is, the requested events can be processed as-is.
+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.
+
+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.