README: unclear discussion of queueing issues

I had a little difficulty following this part of the README:

The decision on whether to accept a device is ultimately made by the caller implementation and non-deterministic.

This sounds like a caller (the application using libei, right?) is intentionally doing something non-deterministic, which I don’t think is the desirable case. I think what this is trying to capture is a scenario where the caller wants to send several events in serial but the sending of any of these may fail in ways beyond the caller’s control. I.e. an API that allowed “send A, then send B” wouldn’t make sense because the sending of A could fail in a way that affects whether/how you want to send B.

Maybe something like this?

diff --git README.md README.md
index 723d482..e3c2607 100644
--- README.md
+++ README.md
@@ -321,8 +321,9 @@ 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
+device is ultimately made by the caller implementation. The caller must be
+prepared to handle failures of any and all events it sends.
+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

It’s basically justifying why an async API wouldn’t work, right? I’d submit the above as a Merge Request, but I think I can’t do this as a fresh account.

Also, here’s a trivial typo fix:

diff --git README.md README.md
index 723d482..8562e4e 100644
--- README.md
+++ README.md
@@ -319,7 +319,7 @@ 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
+The current implementation 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