[feature request] Daemon mode?

[097115]

Probably, not an easy request to implement but just a thought.

What if kirc could be run in daemon mode, and we could also launch other instances as clients, connecting to this daemon and displaying content from the specified channels only?

Like this:

kirc --daemon -s irc.undernet.org -c linux -c freebsd -n MyNick -r MyName
kirc --client -c linux
kirc --client -c freebsd

This way, we could use a terminal multiplexer, like tmux, to have separate channels actually running in separate windows..

What do you think? :)

[kdkasad]

Not entirely sure, but this might be possible using something like socat(1) to splice TCP streams together. Instead of running a daemon and several clients, you can use several normal instances of kirc(1) which all communicate using the same connection via socat(1).

Sure, this isn't the same as having a daemon and clients, but it could accomplish the described result.

[mcpcpc]

This question came up a while ago, regarding kirc supporting a daemon mode, and the the conclusion I came to was that it was out of the scope of the project.

It does not mean that i wouldn’t be willing to support this in other ways though. For example, system notifications (see #73) are available as a shell script in the support documentation. Using that example, i imagine that a simple shell script could be used to parse a log file and check for new messages on a specified channel.

I will take some more time to think about this one a bit. implementation as a main feature is pretty straightforward, so i imagine this could also be made available as a patch.

This would also be a pretty ok solution to terminal resizing. You just reopen the client while the daemon is still connected.

[mcpcpc]

This would also be a pretty ok solution to terminal resizing. You just reopen the client while the daemon is still connected.

true. although what really needs to happen is a rewrite of the implemented text editor to handle proper redrawing of the entire terminal window (and consequently, fix text reflow). i have been toying with this idea for a while now and, given the text editor comprises >50% of the cloc, would result in a near rewrite of kirc.

i am not opposed to this but, if we were to proceed with the rewrite, should we also consider other significant changes? for example, kirc would greatly benefit from switching to a file-based buffer system. this would ultimately open the door to other neglected features, such as multi-channel support. this would ultimately change the inherent behavior of kirc though and may not be favored by the community.

May be worth taking this to a community poll and seeing what else should be considered (if a rewrite were to happen).