run xi-core in seperate thread

[patrickisgreene]

Id actually like to make xrl::Client a trait and then create an Executable & Proccess struct That could be used instead of Client. As a bonus we could implement most of the logic in the trait definition and only need to implement a send and recv method for each.

Pros:

• Doesn't require the user to have the xi-core executable.
• xi-core is relitivily easily updated(recompiled).
• would allow the user to send serde_json::Values directly
• you could switch between them easily(only at compile time).

Cons:

• xi-errors will get sent to stderr instead, they could be collected but thats up to the user.
• would break with xi updates unless pinned to a particular version.
• probably more i'm not think of.

I just wanted to get your opinion before continuing, i've been using xi-core as a library for a few months now and it's made dealing with xi-core(while it's constantly changing) a leisurely breeze.

[little-dude]

Hi @ByteBuddha, I'm sorry last few days were crazy at work, and I have a long flight today, so I don't think I'll be able to really look at this before monday, I hope you don't mind.

[patrickisgreene]

I'm actually going to close this. I think we should wait on this anyway unti xi-editor/xi-editor#439

[Cogitri]

FWIW, Tau has used Xi as a lib for some time, simply sending the RPCs to another thread, like so: https://gitlab.gnome.org/World/Tau/blob/bb377b7fb8909c494cbe970da099a61ec7d47a78/src/gxi-peer/src/xi_thread.rs . I've talked with xi-editor upstream about making Xi easier to use as a system instance, but got the following response (I had suggested adding capabilities to xi to tell the frontend what RPCs are supported):

My personal feeling is that things like capabilities are bandaids over other problems. We aren't a web service; frontends are expected to be bundling the backend, and should always know what version they're running.
As in, I think that vendoring is reasonable. I don't currently think of xi as a system service that should be used by numerous frontends.

So I'm reopening this and will look into doing this in a bit (although I'm rather busy right now :/)

[msirringhaus]

Just wanted to mention: xi-win is doing the same thing
https://github.com/xi-editor/xi-win

[Cogitri]

Ah yes, Tau (gxi) did something similiar, I guess I might go for something similiar with xrl, but I'm not quite sure how to do it in an async manner (maybe future's channels can do that?).

[Cogitri]

So, the current status on this:

I first tried implementing this into xi-editor by enabling it to use a Sender/Receiver pair instead of something that implements Read/Write, but that is a huge change in xi, which potentially breaks plugins.
I then went over to implementing this in xrl instead, but the problem is that I can't seem to find a type that implements both Read/Write and AsyncRead/AsyncWrite, instead only implementing one of those (e.g. the pipe crate only implements the former, while sluice only implements the latter :/)