Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why are I3Connection and I3EventListener separate? #56

Open
jplatte opened this issue Apr 8, 2020 · 2 comments
Open

Why are I3Connection and I3EventListener separate? #56

jplatte opened this issue Apr 8, 2020 · 2 comments

Comments

@jplatte
Copy link
Contributor

jplatte commented Apr 8, 2020

It seems they both access the same socket file, why are they separate types? Currently, if I want to get the current workspace state at the beginning of my program and then all subscribe to workspace updates, this requires opening the socket file twice.

@brownjohnf
Copy link

Is your question around why this implementation separates them, or why you'd want to separate them more broadly? The i3 IPC docs say (emphasis added):

Caveat: As soon as you subscribe to an event, it is not guaranteed any longer that the requests to i3 are processed in order. This means, the following situation can happen: You send a GET_WORKSPACES request but you receive a "workspace" event before receiving the reply to GET_WORKSPACES. If your program does not want to cope which such kinds of race conditions (an event based library may not have a problem here), I suggest you create a separate connection to receive events.

Just off the top of my head, it seems like it should be okay to open the connection once, send a bunch of non-event subscription messages, and then subscribing to events and continuing with the program. I have a use case where I want to send messages while receiving events, and it's much more straightforward to just keep a second connection open.

That said, there's probably a way to unify the interfaces such that you can create a single connection, and calling subscribe will start streaming events.

@jplatte
Copy link
Contributor Author

jplatte commented Jun 30, 2020

there's probably a way to unify the interfaces such that you can create a single connection, and calling subscribe will start streaming events.

That would be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants