schapps/posts/background-software-as-a-routine.rst

.. title: Background Software As A Routine
.. slug: background-software-routine
.. date: 2024-10-30 8:22:04 UTC
.. tags: atom, bittorrent, chat, cli, console, daemon, gtk, interface, library, liferea, module, rss, server, software, syndication, toolkit, xmpp
.. category: journal
.. link: background-software-as-a-routine
.. description: A crucial consideration for independency and longer sustainability.
.. type: text

Good day!

This post suggests to consider to build software as background software
(sometimes referred to as so-called "daemon" or "server") and build, in addition
to it, a companion software, which would be utilized as an interface to the
background software.

Liferea and GTK+ toolkit
------------------------

Earlier this week, I was informed, that Mr. Lars Windolf, the maintainer of a
popular desktop and office software, Liferea, intends to cease from maintaining
it.

From reading the fourth paragraph of the announcement which was published at
`lzone.de <https://lzone.de/liferea/blog/20-years-of-Liferea-and-the-future>`_,
I have concluded that the prominent reason, for his intention, is the unexpected
maintenance costs and requirements that are consequent to the changes that have
been made to the graphical toolkit called GTK+.

> Looking back at those 20 years for me the GNOME ecosystem developed in a way
that the maintenance work was ever increasing. The different aspects of this are
the major GTK releases causing massive refactorings, continuous API deprecations
causing compiler noise and work that does not benefit the features. So every
time I was close to dropping the project, the reason always was the GTK
development cycle.

And the paragraph ends with a mention of libxml2.

> This is for example different with another important library for Liferea:
libxml2. The API was practically 95% **stable** for 20 years.
**Zero maintenance effort!**

This is not a positive matter, unless lessons will be learnt and measures to
avoid such undesirable indicents be practiced.

FLTK and SDL toolkits
---------------------

FLTK appears to be a viable toolkit for Liferea and other projects of sort.

So it is for SDL which the Gemini browser
`Lagrange <https://gmi.skyjake.fi/lagrange/>`_ is built upon.

Qt toolkit
----------

It has already happened in the past, with other prominent projects such as
`LXDE <https://blog.lxde.org/2013/04/25/a-guide-for-porting-gtk-applications-to-qt/>`_
which has later formed into `LXQt <https://lxqt-project.org>`_ and
`Wiresark <https://blog.wireshark.org/2013/10/switching-to-qt/>`_ which was
migrated from GTK+ to Qt due to consequences of decisions that were made for GTK+.

It will be interesting if The GIMP would also switch to utilizing Qt or FLTK.

Background mode
---------------

Some software have a good interface, be it command line, console or graphical,
and some software have a good core, and some software have both.

Sometimes, new modules (sometimes referred to as "libraries" so-called), are
created and replaced by older modules.

For example, the XMPP chat client software `PyTalk <http://pytalk.trunat.fr>`_
and `Speeue <https://github.com/thepug/Speeqe>`_ are both based on the Python
module `xmpppy <http://xmpppy.sourceforge.net>`_; PyTalk offers a Qt interface,
and Speeqe offers an HTML interface to interact with people who desire to
communicate via the XMPP communication network.

The module xmpppy is built for version 2 of the computer language Python, which
was replaced in favour of the version 3 of the computer language Python, and is
not present on most systems nowadays.

By all means, this does not mean that PyTalk and Speeqe are obsolete, but it
does mean that restructure of these software be required in order to easily
deploy them on most systems.

Yet, if Speeqe and PyTalk would have been built into a couple or triple of
components (e.g. core, background, and interface), both would have been usable
on most systems, even today, provided that the background software be rebuilt or
redesigned with a more current module (e.g.
`Slixmpp <https://codeberg.org/poezio/slixmpp>`_) instead of xmpppy.

BitTorrent clents as an example
-------------------------------

It is interesting, that BitTorrent software, such as qBittorrent, RTorrent and
Transmission, to name just a few, tend to be modular, and are often provided in
several forms of background, console and graphical interfaces, and the core is
the library that each utilizes to communicate in the protocol BitTorrent.

A common functionality, that BitTorrent clients have, is remote control, usually
via the the protocols HTTP and XMPP.

There is a variaty of advantages that are realized when background components
are made available, one of which is the facilitation of adding functionality for
remote control.

Music On Console
----------------

Another instance, is `MOC (Console audio player) <http://moc.daper.net>`_,
which, despite its title, it is compartmentalized into a triple of complonents,
a background process, a command-line interface and a console interface to
visually interact with it.

Conclusion
----------

Building software in several modes with, at least, background and interface, is
a basic and yet **crucial** consideration in order to ensure the sustainability
and independency of projects, and not to be relied on the whims of a toolkit
lord.

Best regards,
Schimon