Local sockets (more flexible alternative to pipes)

[erikLundstedt]

would it be possible to add an argument of some sort (or probably multiple) to at runtime specify where to put or what to call the "named" pipes for piped in-out data

this could be used to have external programs interact directly with a spesific xplr session without needing to be in the form of a plugin

one example could be interacting with xplr using a keybinding in a compleately different program, such as a terminal(wezterm)
or integreating it with an existing bookmark manager for example

it allso makes it possible to write the external code in something other than bash/lua (I would love to be able to write a pluggin in fennel(lisp) as an example)

[sayanarijit]

Pipes would be really inefficient for that purpose and will make xplr slow or increase the complexity. I think implementing something like a socket server will be a better idea. With socket, xplr will really behave as a server, handling external requests and responding to them.
But we need to be careful about the permission model. I wouldn't want an unpriviledged program to interact with xplr running as root.

[erikLundstedt]

Pipes would be really inefficient for that purpose and will make xplr slow or increase the complexity. I think implementing something like a socket will be a better idea. With socket, xplr will really behave as a server, handling external requests and responding to them. But we need to be careful about the permission model. I wouldn't want an unpriviledged program to interact with xplr running as root.

that sounds perfectly fine
do you want me to post a modified issue or will this work despite incorrect title/main content?

[sayanarijit]

No it's fine. It was only my initial opinion. It's still up for discussion. If anyone has any suggestion, feel free to comment. I'll try to explore the options as well.

[erikLundstedt]

Pipes would be really inefficient for that purpose and will make xplr slow or increase the complexity. I think implementing something like a socket server will be a better idea. With socket, xplr will really behave as a server, handling external requests and responding to them. But we need to be careful about the permission model. I wouldn't want an unpriviledged program to interact with xplr running as root.

I personally think the model used by something like tmux works quite well
the main reason i suggested using a pipe was development speed as that is what is already highly integreated

[sayanarijit]

Pipes are convenient but come with several limitations. One major limitation is performance. That's why pipes are designed to be one-shot thing. They don't update in real-time and don't keep listening to incoming messages. They are created, used and deleted while xplr stays in idle.

To keep listening to messages and responding to them in real-time while xplr is active, without impacting the performance, there needs to be a server running on a separate thread, that will contain a reference to the implement some way to interact with the active xplr session. Also, we need to implement the api for querying the state of xplr session efficiently. This will be another alternative to pipes, lua function calls and keyboard inputs to interact with xplr.

The tmux socket model looks good. But I'd say we need to research more on this as this will be a big change.