-
Notifications
You must be signed in to change notification settings - Fork 209
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
mpd: Allow mpd connection via UNIX socket #349
base: master
Are you sure you want to change the base?
Conversation
Instead of using a string instance's sub() function we can instead use the global one to clean things up a bit
ok, I've added a basic implementation of a send to unix socket w/ lua-lgi (because I had no internet and had nothing else to do ;0) The main issue is going to be maintaining that async format - I'm really rather new to lua so idk if there's an easy way to do it |
Both network methods appear to work in isolation, just gotta see if they work when integrated properly. Saves anyone else diving into LGI I guess
helpers.lua
Outdated
@@ -15,6 +15,8 @@ local io = { lines = io.lines, | |||
local rawget = rawget | |||
local table = { sort = table.sort } | |||
|
|||
local gio = require("lgi").Gio |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, rename the variable to Gio
, for consistency.
I appreciate your efforts, but don't reinvent the wheel. My aim is to generalise this as a But, using |
Literally just as I get it to work properly over Gio streams as well >__< Eh I'll see if I can get that to work instead, SocketClients make me want to cry |
end | ||
|
||
return recv_buffer | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return string.rep(" ", buffer_length + 1)
(the +1
is there to match the behaviour of your code, but I don't know if your code really should do that)
output_stream:read(recv_buffer) | ||
output_stream:read(recv_buffer) | ||
|
||
callback(recv_buffer) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... this will actually "break Lua". Lua assumes that strings are immutable. So, e.g., if any other piece of code constructed the same number of blanks before, the received data will also end up in there.
Also, you should conn:close()
when done.
(Note that I just looked over this in a drive-by fashion, @copycat-killer gets to decide things and I have no say in anything here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@psychon I appreciate any review of yours, for me you are free to come by as you like.
heh, it must be pretty obvious that I'd never used lua before writing this I guess T'is a silly language |
cd4f448
to
794f5d3
Compare
b14a2c8
to
055e663
Compare
d2fd3d5
to
24ca585
Compare
112fcae
to
cf8ef78
Compare
1291b1c
to
012c6b6
Compare
what more needs to be done here? just a rebase w/ current head to get rid of the merge conflicts? |
@lcpz Do you know about https://awesomewm.org/recipes/mpc.lua already? It connects to mpd over either TCP or a unix socket and provides an asynchronous API for talking to the daemon. |
@psychon The idea was indeed to readapt that. No need to reinvent the wheel. |
ok.. i'm taking this up. do you want a stateful socket that tries to reuse the connection as long as possible, or do you want to go the direction that @FloatingGhost is headed with reconnecting every time for a request/response? |
@razamatan The idea is still this. Hence, sockets. Try to work with the above-mentioned code, it should be easy. |
stateful sockets, got it.. i started this and i'm working it out now. |
hmm... while making the socket helper/class generalizable, the socket protocol is too ambiguous to make the helper/class useful beyond some initial connection boilerplate. the central read loop needs to be implemented per protocol/usage: http things would go one way, imap another, mpd has it's own client-initiated conversational api, etc. etc. once i gutted the main read loop to be a user-defined callback, it really isn't much. i could make it a base class for each client/protocol to implement/inherit, but i'm not sure that's what you really wanted here. also, why the preference for UnixInputStream over DataInputStream? |
You could create a protocol submodule which, for the time being, provides MPD connections only. In the future, we can also add HTTP(S) and IMAP (and finally remove Curl as a dependency). Feel free to push WIP commits, if you want my commentary as you work. We can squash them when you are done.
Because the former is pollable, while the latter is not. But it is no religion: feel free to show me that DataInputStreams suit better. |
qq.. what's more important, not taking on any dependency at all, or not adding a non-lua approach? the more and more i'm dealing w/ this lgi wrapped GIO stuff, the more i am inclined to say that luasocket may be a better fit here. |
@razamatan There is already a non-Lua approach: it's Curl, which has also been preferred over LuaSocket for these reasons. EDIT:
Actually both. Once we base on GIO, we won't have any dependency at all, Lua or non-Lua. |
@razamatan Anything I can help you with in LGI? Does perhaps already lgi-devs/lgi#243 help you? Another helpful pointer could be |
i have things working fine for mpd using lgi and UnixInputStream as requested, but for http, it's a bit more complicated. in order to be robust against all the different possible protocol versions, ssl, redirects, and all the features of the http spec, it's redundant to roll yet another http client. being open source, i could just grab their http.lua and just refactor it to be only client focused and gio based. still, more time taken. the PITA for lgi is that it doesn't have any method level documentation (showing input and return values) since it does things to make the lua binding more lua like. the overview and guide explain things, but it's much, much easier if there would be just something that shows all the available methods and their signatures. i've been relying on pgi docs online and testing things to verify behaviors. |
I think "the way to go" with Gio and http is to just open an URL as a file, but that requires a new package whose name I forgot (something like gio-networking). With that, https://developer.gnome.org/gio/stable/GFile.html#g-file-new-for-uri should just work. |
the file abstraction may be fine for terminal rpcs like http requests/responses, but for persistent client/server connections like mpd which prefers keeping the connection alive using idle commands, the file abstraction might not be the best thing. |
a5b407f
to
a955bbb
Compare
so work got a bit lighter, so i'm picking this up again. Gio.File seems to do what we want for most cases (as mentioned by @psychon) that just wants to download a full file, but it requires making sure folks have gvfs installed so gobject-introspection picks up uri support in gio. the alternative of going w/ the UnixInputStream approach is that all protocols need to be implemented at the socket layer, which is a tax on ongoing maintenance (i was doing this route, but shelved it after psychon's suggestion). However! i found that lgi supports libsoup, which is the level of support we care for anyway, so i got that working. @lcpz are you ok with taking a dep on lgi w/ libsoup? people who aren't gnome heavy won't have it installed like me (i run a pretty lean X in gentoo). |
@razamatan Thank you for your work, and for sticking around for so long! I appreciate it. I understand that having no dependencies requires utilities that need to be maintained, which is not reasonable. Thus, I think What do you guys think? |
wouldn't using libcurl end up with another dependency on top of it to handle the c <=> lua handling? i understood #349 (comment) to limit the number of things that users would need to install on top of awesomewm. so, lgi => gi => gio|soup was what i thought was wanted. all this said, unless gnome is thinking of removing libsoup, i don't think it's a bad dependency to take. |
I mean to say that there is already But I am open to thoughts. |
but the usage of curl as a spawn shell command is the root of the issue, right? if we want to move to an all lua interface for these rpcs, we would take on luacurl or some other lua wrapper for libcurl as another dependency.
so either some lua->curl wrapper, or making sure folks have libsoup installed so lgi supports it. my feeling is that people who are already in the world of gnome/gobjects likely will have libsoup installed, but most folks won't have a lua wrapper for libcurl installed.
…________________________________
From: Luca CPZ ***@***.***>
Sent: Sunday, January 15, 2023 1:59 PM
To: lcpz/lain ***@***.***>
Cc: razamatan ***@***.***>; Mention ***@***.***>
Subject: Re: [lcpz/lain] mpd: Allow mpd connection via UNIX socket (#349)
I mean to say that there is already curl as a dependency, which seems better than libsoup, so it's not worth to switch.
But I am open to thoughts.
—
Reply to this email directly, view it on GitHub<#349 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAD53T4HVCMSF4K27YQOD2TWSRXLDANCNFSM4DTBIVHQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
you know what.. i'm going to see if i can just use basic lua -> c behaviors to avoid using a canned lua->libcurl wrapper as a dependency. i don't think we need a whole lot of functionality. this way, no new deps, and it'll be easier to migrate from |
(to clarify the previous comment) i came to this conclusion b/c https://github.com/Lua-cURL/Lua-cURLv3 (lua-curl; note the hyphen) is the best that's out there for lua and libcurl afaict, and it hasn't been touched in over a year and a half. luacurl's (non-hyphenated) public repo seems to be no more. if i don't get something going along the lines suggested in the previous comment that seems easy to maintain in a few more hours, i'll give up and settle on libsoup b/c: 1. gnome supports it 2. gi supports it 3. lgi supports it 4. it works in #549. this feels much more stabler than relying on some lua-?curl impl... |
ok.. i learned how to call c from lua, and i don't want to maintain another lua*curl wrapper. we don't need another in the world as lua-curl(v3) should be sufficient. however, i don't want to go off and help maintain that library either. the lightest maintenance cost is going to be whatever we can get cheaply from lgi, so libsoup as i implemented it is the simplest. let's go with it. |
Previously, the mpd widget couldn't communicate via a UNIX socket, leading to it being basically useless in that case.
We can use exactly the same command sent through
socat
to fix this, which this implements.