Jami DBus interface no longer avaliable after Arch Linux switched from jami-gnome to jami-qt

Developers
1

Hi all,
It has been a while I worked on my Jami bot. I decided to revisit it this morning. My previous bot project uses the DBus interface provided by jamid to send/receive messages. However, seems after Arch decided to switch from jami-gnome to jami-qt. The jamid disappeared form the jami-daemon package. And launching jami-qt does not make cx.ring.Ring available on my session bus/system bus.

How can I access the DBus API now? Is it deprecated?

2

The dbus API is still supported, however for performance reasons the Qt client now uses a single-process model.

3

Thanks for the reply. Does that mean I can’t run the Qt client and jamid at the same time? Or does both clients not conflict with each other.

4

The proper way would be plugins to do a chatbot (or ideally just jamid with a script on top of it),

But on Arch subject, basically we have two ways to use Jami (in fact more than two, but let’s summarize):

  • DBUS (will give 2 processes)
  • single-process (what jami.net release)

Generally, even in the second case the jamid binary still exists and is available for dbus, but on Arch I don’t think it’s the case:

I think the Arch packager disabled dbus recently for two reason:

  • It’s what we do on jami.net
  • dbuscpp is heavily deprecated (not maintained for nearly 10 years) and it doesn’t build on gcc 12

We may re-introduce a package like jami-dbus for jami.net (but we do not maintain packages for Arch Linux) but one other way would be to build jami from sources with ENABLE_LIBWRAP=False to use the dbus API by default (I think Arch has a way to build a package from sources (git packages)).

1 Like
5

I was planning for a similar scenario as the original poster:

  • headless jamid
  • one or more bots/gateway services, etc. running 24/7

DBus up to now would have been the “natural” choice as an interface for this scenario.

I found the architectural decision to split communication logic and UI logic pretty nice. The most convincing reasons being high flexibility for UIs and being forced to adhere to a formal interface.

The focus on QT today may have shifted your priorities from the process interface to the UI, however IMHO it would be nice to leave the door open either for implementation of UIs running w/o QT, or at least for a headless mode with a plugin interface. The potential of plugins is then restricted by the available plugin interface.

An available interface opens the distributed infrastructure of jami to become a platform for all kinds of (automated) services, which may help with expanding its influence.

For my usage scenario, I am unsure whether to proceed with Jami or with another solution after what I have read here.

Kind regards,

Alex

6

DBus is exactly done for this and is still available for this (jamid in the package is still controlable via dbus and you can plug it to any script/client e.g. jami-cli GitHub - AmarOk1412/jami-cli: Jami client for terminal or even jami-qt if built with dbus).

And this dbus interface is not planned to be changed and will stay

7

For the currently distributed jami that is what I understood from your first explanation.

Thank you for the quick reply and for pointing out, that dbus is there to stay.

How does your remark about dbuscpp being deprecated fit in? This led to my conclusion that dbus was about to be phased out.

Regards, Alex.

8

dbuscpp should be replaced by another lib, but it’s not a priority and the dbus system doesn’t evolve much anyway

9

I see there’s a patch to fix GCC12 build in jami-daemon .I52d4fee70c9fdcc38c964301d56f89fa23188e9a, Does that mean this is a packaging issue now?

Also I think I can port the dbus code into using the C++ wrapper of sdbus. Given there’s enough demand for this. I love the idea of Jami and is sad that my bot doesn’t work anymore.