-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
Also - how do I 'un-export' a service when I'm done with it (other than exiting the process)? |
Hi! Regarding exporting multiple services: I think you can achieve this by instantiating multiple Regarding unexporting a service, it is possible in a crude way by calling |
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.
Fixed in #135, released 0.23.0.beta1 |
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:
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:
Even if you try to trick the library requesting 2 "services" and exporting the
objects on the latter one which gets remembered internally:
It will kind of work, eventually producing the object tree what you want, but
importantly for autostarted services, the second
request_service
call willalready start processing method calls for the objects that haven't been
exported yet. So the first method call will fail.
Original report:
The text was updated successfully, but these errors were encountered: