System Tools Backends NG

This wiki page is a whiteboard for the structure of the next major version of the System Tools Backends

Current status

The Current backend/frontend comunication has several issues, first the backends return/accept data in XML, which is good, but comunication has to be still done by hand (for example the modemlights applet, >90% of the code is aimed to authentication/comunication/...), it's clear that the backends already abstract a whole bunch of stuff, but seeing that this code for comunicating will be repeatedly all over the modules that would need the backends, it sounds like a good idea to create a common abstraction to this too.

Another problem of this comunication is that it doesn't allow notifications from the backend to the frontend, making necessary for the frontends to poll constantly for changes, and only allows a single request at a time.

Possible future

So the next version of backends should have:

An API for abstracting the comunication, besides abstracting too the config task
A signals system for handling notifications from the backends
Exception/Error handling
Abstract as many things as posible (extending backends functionality)
- Basic package managing (This will require notification from the backends to know the status:
  - downloading, installing, configuring, compiling, errors...)
- Routes
- Cron
- Firewall rules
- Basic process management
- ...

For this, the big candidate for replacing XML is DBus, DBus allows sending complex data (structs, arrays, ...), but sending the whole config won't be the correct approach if we want to make a decent wrapping API.

A thing to think about is the integration with FAM/Gamin, (to spread "changed" signals when affected files are modified by other media), but it would require much more engineering, as it would leave inconsistent data (i.e.: having modified data which no longer exists in the config file, etc...).

Another topic would be the integration with HAL, as some of the config task is quite related to Hw, the best would be leaving the backends isolated from HAL, and doing this integration in the bindings level, this would be pretty straighforward if all the comunication channel is done through DBus.

API Level

Inclusion of the backends in FreeDesktop is still pending, so here I'm describing a draft about how could the GObject based API be, but a QT API could be build on top of this as well:

StbSession (Might be necessary for handling session with the backend? authenticated vs non-authenticated, ...)
StbCollection (Object necessary for tracking changes from the backend? If we're not going to handle this, we might get rid of it)
- StbIifacesCollection
- StbDNSCollection
- StbSearchDomainsCollection
- ...
StbStaticHost
StbRoute
StbIface
- StbIfaceEthernet
  - StbIfaceWireless
- StbIfaceIrlan
- StbIfacePlip
- StbIfaceIsdn
  - StbIfaceModem
- ...
StbService
StbUser
StbGroup
StbPackage
StbProcess
...

What should we aim for

Instead of writing 1KLOC in modemlights for connecting, authenticating, polling, and queueing directives to the backend, it should be as easy as:

static StbIface*
iface_construct (void)
{
  StbIface *iface;

  iface = stb_iface_get_first_by_type (STB_IFACE_MODEM);
  g_signal_connect (G_OBJECT (iface), "changed",
                    G_CALLBACK (on_iface_state_changed), NULL);
  return iface;
}

...

static void
on_iface_state_changed (StbIface *iface, gpointer data)
{
  if (stb_iface_get_enabled (iface))
    {
      ...
    }
  else
    {
      ...
    }
}

...

static void
on_enable_button_clicked (GtkWidget *widget, gpointer data)
{
  StbIface *iface = (StbIface *) data;
  stb_iface_enable (iface);
}

...

static void
on_disable_button_clicked (GtkWidget *widget, gpointer data)
{
  StbIface *iface = (StbIface *) data;
  stb_iface_disable (iface);
}

Profiles/Locations/etc...

It's still necessary to store information relative to a setting or a location (i.e: networking config, users profiles, etc...), ideally this would need to be though in a desktop wide way. At least, the backends should provide the possibility of storing the profiles for a concrete set of settings (might not be necessary for ALL the config, for example, having locations for bootloader configuration makes no sense).

Ease of modification

Currently for giving support to a new distro, one has to modify a bunch of code files, if the distribution requires hard modifications, it's unavoidable, but given the current state of the backends, the most common thing is to modify just the mapping hash tables to say that distro X behaves like distro Y regarding Z, this setting should be centralized just to make it as easy as possible for new people to add this kind of support.

Which would be the timeframe for this?

While the timing for modifying the backends isn't estimated (and won't be probably accurate), my guess is that it would take at least 2 gnome release cicles to create the correct infrastructure for all this, extending the functionality a bit and modifying the frontends to match the changes, so there's work to do