Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: can I export multiple services from a single process - dbus restriction? #69

Closed
mistergibson opened this issue Dec 17, 2017 · 3 comments

Comments

@mistergibson
Copy link

mistergibson commented Dec 17, 2017

I'm not sure if I got your question right but I will repurpose this report for my current problem:

A connection can have more than one well-known name (the letter-dotted one), ruby-dbus doesn't support it.

For example on my desktop I have one connection using 3 well-known names:

$ busctl --user | grep Thunar
NAME                          PID PROCESS USER   CONNECTION UNIT            SESSION DESCRIPTION
:1.18                        2448 Thunar  martin :1.18      session-1.scope 1       -
org.freedesktop.FileManager1 2448 Thunar  martin :1.18      session-1.scope 1       -
org.xfce.FileManager         2448 Thunar  martin :1.18      session-1.scope 1       -
org.xfce.Thunar              2448 Thunar  martin :1.18      session-1.scope 1       -
$ busctl --user tree org.xfce.Thunar
└─/org
  ├─/org/freedesktop
  │ └─/org/freedesktop/FileManager1
  └─/org/xfce
    ├─/org/xfce/FileManager
    └─/org/xfce/Thunar

This is persumably to offer a custom Thunar interface as well as a common FileManager interface.

Another use case is to implement multiple loosely related services in the same
process to save on memory overhead (like Agama Manager+Users).

Currently ruby-dbus cannot do this,
it assumes that your service has exactly one well-known name and you call:

service = bus.request_service("org.example.Widget1")
service.export(Widget.new("/org/example/Widget1"))
some_main_loop.run

Even if you try to trick the library requesting 2 "services" and exporting the
objects on the latter one which gets remembered internally:

s1 = bus.request_service("org.example.Widget1")
s2 = bus.request_service("org.example.Gadget1")
s2.export(Widget.new("/org/example/Widget1"))
s2.export(Gadget.new("/org/example/Widget1"))

It will kind of work, eventually producing the object tree what you want, but
importantly for autostarted services, the second request_service call will
already start processing method calls for the objects that haven't been
exported yet. So the first method call will fail.

Original report:

Dear Developer:

Can I export more than one service (assuming differing names of course) from a single process? I noticed that you use class variables instead of instance variables for the interface.

Thanks,

G.

@mistergibson
Copy link
Author

Also - how do I 'un-export' a service when I'm done with it (other than exiting the process)?

@mvidner
Copy link
Owner

mvidner commented Dec 21, 2017

Hi!

Regarding exporting multiple services: I think you can achieve this by instantiating multiple Connections, specifically ASystemBuses or ASessionBuses. But I have never tried this so it is possible that something breaks it.

Regarding unexporting a service, it is possible in a crude way by calling ReleaseName, see the file server_spec.rb for an example.

mvidner added a commit that referenced this issue Jun 3, 2023
The Service class was serving client and server roles and its #root
tree had ProxyObject or DBus::Object leaves respectively.
User code should not instantiate it directly so the breakage will
hopefully be small.

The main motivation is fixing #69:
serving more than one well-known service names.

ObjectServer, the service-side successor, no longer has any name
(BusConnection, as yet not existing Connection subclass, will
have 0 or more well-known names in addition to its unique name)
It is returned by Connection#object_server and by the deprecated
Connection#request_service.

ProxyService is returned by Connection#service.

Internal changes:
- Renaming `bus` to `connection` where appropriate, not all connections are to
  a bus (but not aiming to fix peer connections right now).
- Object#@service is deprecated, surviving until I figure out the prefered API
  to manage object trees. Object#connection introduced.
- Connection#@service is gone, use Connection#object_server.
- No longer set our name to emitted signals, the bus will overwrite it to our
  unique name anyway.
@mvidner
Copy link
Owner

mvidner commented Jun 5, 2023

Fixed in #135, released 0.23.0.beta1

@mvidner mvidner closed this as completed Jun 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants