Post #1496863

2026-03-02 11:47 UTC

@pid_eins the `more` support and keeping connections open can easily be implemented with just native HTTP without having to switch to websockets. Doesn't even have to be SSE. Can just be a response that streams its results and splits the stream by NUL byte. The varlink semantics of queuing multiple requests and the need for responses to come back into the same order as requests makes it behave basically the same semantics as HTTP 1.1 Map each HTTP path to a varlink method call. And map the parameters to the request body Then simply stream back the reponse of the varlink call back over the http connection. If the varlink response streams multiple answers, just keep the http connection open Here is an example that reuses the same varlink connection over multiple HTTP calls; works fine! I really don't see the need for websockets here Here's a demo in a few lines of go: https://gist.github.com/arianvp/314113d4309c7d7d3047535e167352ac

Replies (2)

@pid_eins@mastodon.social 2026-03-02 16:21

@arianvp so the bridge supports both the ws and the non-ws mode iirc. @michaelvogt please comment. (the other reason why ws is sometimes nice, is that varlink knows a concept of upgrading protocol, i.e. just being something to set up a connection and then switching to something else)

Open ##1496864
@michaelvogt@mastodon.social 2026-03-02 16:50

@arianvp @pid_eins Thanks Arian for the gist! The main reason for the websocket stuff is/was the protocol switching that Lennarts mentioned. But of course your right that just for the --more we won't need it and can use http streaming or SSE. I expect that we will add either http stream or sse (or both) pretty soon to make it easier for traditional curl usage to call e.g. io.systemd.JournalAccess.GetEntries. But I also want to make sure we DTRT so this kind of feedback is much appreciated!

Open ##1496868