So, to answer this then, my current project is Circle, an IRC client. Actually, it's much more than an IRC client, but that will do as a first approximation.
Rather than being Just Another IRC client, this one is split into two programs; a backend server that runs on some machine somewhere, likely your co-located shell hosting box, or home server. This maintains all the connections to the IRC networks, persists the scrollback and so on; it is the guts of the logic. Then there's the frontend program, a lightweight GTK application that draws the UI for the backend logic. The frontend doesn't really understand IRC, the backend has no knowledge of GTK. Several readers may recognise something of the MVC pattern about this.
Without going into too much detail here (you can read the above link), this gives you the advantages of a real local native-UI client, plus the advantages of a persistent server. The UI interactions are local, no network latency or bandwidth to get in the way of line editing, backbuffer scrolling, window switching, and so on; yet all the data is persisted in the server so you can just disconnect the thin client and reconnect it from anywhere else.
A common way people usually solve this sort of problem is to run irssi in a screen session, and reconnect over SSH. The primary downside of this setup is it requires a low-latency, high-bandwidth connection to the server, as every keypress of the line editor to send your next line, will have to round-trip over that network. Every backbuffer operation, scrolling up and down, or switching between windows, has to redraw over the link. If that link has high latency, or low bandwidth, the user experience will suffer. If the network charges for bandwidth, you will end up paying many times to keep re-sending the same screenful of scrollback as you switch windows. By not having a real presence on the local desktop, irssi-in-screen also cannot take advantage of local desktop features such as notification sounds or highlight popups, nor can it access the local filesystem to perform DCC transfers or similar.
Another solution to remote persistant IRC is to run an IRC proxy server or bouncer, and point a regular IRC client at that. These either don't support backbuffer refills, or save and replay events, possibly by prefixing timestamps in the message text. They suffer many shortcomings by being a hacked-on proxy in front of an existing IRC client, which overall doesn't really support the disconnect/reconnect model. These solutions almost exclusively are also IRC-specific, and cannot integrate non-IRC (such as Instant Messaging) alongside.
Right now this is pretty-much all there is to it, though the design is such that it can accommodate much more. There's also a plain telnet-alike backend module, but it could quite easily accept Instant Messaging, Email, PIM, whatever. Right now, the only frontend is GTK, but nothing says one couldn't also be written for Qt, Windows, or any other GUI toolkit. I'm also slowly in the process of writing a terminal-mode one.
The code is available on CPAN:
- Circle (backend)
- Circle-FE-Gtk
Would it (Circle) support client-side scripting in Perl?
ReplyDeleteThat sounds awesome.
ReplyDeleteI think there will be many people who would want to use the features of this without having a full server or any server at all. Will it be possible to install it on a regular shared hosting web server? Will it be possible to offer a (paid ?) service providing the server side of this?.
Regarding front-end, I'd prefer wxWidgets so that it can be easily installed on top of Strawberry Perl professional for Windows, but as you wrote someone could write that. Hmm, maybe as a plugin of Padre?
@Jakub Narebski:
ReplyDeleteI don't see why it can't do scripting. That said, the whole point of "scripting" is to make the program do something the original author didn't intend. Currently I'm the only real user of it here, so I haven't had much need of that. What sort of things did you have in mind?
@szabgab.com:
ReplyDeleteShared web hosting? I doubt so. The frontend and backend connect currently over an SSH connection. It just requires "some reliable stream" to connect the two, and with a bit of mangling, a bidirectional record-based connection would do just as good. You'd still need a way to push messages at arbitrary times in either direction, though. I'm not sufficiently up on current web technologies to know if such a thing is possible.
As to frontends in other widget toolkits - yes, that's exactly the point here. If someone wants to run it on something other than GTK, then all they have to do is rewrite the frontend, not the entire backend logic.
According to 'wc', backend has 6522 lines, while GTK frontend a mere 1091. As you can see, most of the logic is in the backend, thus minimising the work required for a new toolkit.
@LeoNerd: I am thinking here of the example of scripting in X-Chat (possible also in Perl). Things such a DCC fileserver on one hand, and filtering out fileserver responses on the other hand, or /rot13 command.
ReplyDelete@Jakub Narebski:
ReplyDeleteAll those three tasks sound like backend tasks to me, not frontend. Furthermore, fileserver and rot13 surely have better solutions not in an IRC client, and general filtering is already part of the generic /rules system..
Frankly, I'm much more concerned about full support for all the features enumerated in RPL_ISUPPORT (numeric 005, as reported by either connection or the VERSION command) so that functionality can be provided (similar to splitting messages over multiple lines when a maximum length has been reached) which transparently does things without the user having to worry about it. (e.g. splitting long outbound mode chains behind the scenes, etc.)
ReplyDelete@LeoNerd: DCC fileserver is specific example of triggers, and this should truly be a backend script, plugin or extension.
ReplyDeleterot13 is useful on some channels to post information that can be considered spoiler. This feature resides somewhere in the area between frontend and backend, as it is command invoked by user, and it is about translating written data and received data (descrambling).
Another purely frontend side script would be plugin that uses different algorithm for coloring nicks, so that different nick are visually different (different colors, different lengths). Yet another would be e.g. posting currently played song (from frontend neighbourhood).
Hey,
ReplyDeletethis looks cool. One possible typo--did you mean "Patches, _as_ they say, are welcome"? (Also please feel free to delete this comment if that's not a typo or after the typo is fixed, it will just be noise at that point.)
mike