Add callback parameter to monitored proxy

[jcrd]

If provided, the callback will be called with two parameters: the proxy object, and a boolean that is true when the DBus name appears and false when it vanishes.

[stefano-m]

Hello and thanks for your contribution!

I apologize in advance but I will be a bit slow in responding, please be patient with me.

If you don't mind, I'd rather prefer to start a conversation in an issue rather than having just a PR. Could you do that next time please?

What would be the use case for this feature? Can you give an example please?

Once we agree on the feature, please do add a test and an example in the README. Also, the online documentation should be updated.

As a matter of style, I would avoid if ... then ... end on a single line and instead span them on multiple lines.

[jcrd]

Hi,

Sorry for not opening an issue to discuss this first.

This feature allows reacting to the appearance of DBus names. In my case, I want to create proxy objects for other exported interfaces when the monitored name appears and remove them if it vanishes. Something like:

local function callback(proxy, appeared)
    if appeared then
        for _, obj_path in ipairs(proxy.ObjectPaths) do
            proxies[obj_path] = dbus.Proxy:new {
                ...
            }
        end
    else
        for p in pairs(proxies) do
            proxies[p] = nil
        end
    end
end

local main_proxy = dbus.monitored.new({
    ...
}, callback)

[stefano-m]

Hi again @jcrd and sorry for the late reply.

I think I understand what you want to achieve.

I am not against adding this feature, but then why limiting to only one callback function? Wouldn't it be more useful passing an array of callbacks so all of them can be called in turn?

For example, one could call all callbacks in the given order when the proxy is available and then call them in reverse order when it disappears. I'd be interested in your thoughts about this.

Regardless of how this is going to be implemented, we need the following:

0. ensure coding style is consistent
1. add tests for the feature
2. add working example to the documentation
3. regenerate the documentation

Do you think you can do that once an implementation is agreed?

Thanks

[jcrd]

I hadn't considered the need for multiple callback functions. You could always run these functions in the callback itself:

dbus.monitored.new({
    interface = "example",
}, function (...)
    func1(...)
    func2(...)
end)

Is running the callbacks in reverse order when the DBus name disappears meant to allow multiple setup/teardown-type functions to be "registered"? I have yet to encounter a need for this, but perhaps it would be useful for complicated DBus services.

It shouldn't be much more code to implement it this way, so if you want the flexibility, I can do it. Either way, yes to all of your points. Do you want these changes force-pushed in a single commit?

[stefano-m]

Is running the callbacks in reverse order when the DBus name disappears meant to allow multiple setup/teardown-type functions to be "registered"? I have yet to encounter a need for this, but perhaps it would be useful for complicated DBus services.

That was my thinking, although I don't have any use case. I was mostly brainstorming to avoid the introduction of more, potentially breaking, changes in the future in case one wanted to trigger more than one callback.

It's true that this complicates the testing though.

Reading your answer, there seems to be no compelling argument in making the code more complicated. So, let's keep it simple and limit it to a single callback function for now.

Either way, yes to all of your points.

Cool. Thanks for that!

Do you want these changes force-pushed in a single commit?

I don't really mind, I will get a patch from the PR with all the changes anyway as I don't like merging (you will still be the author of the change of course!).

[jcrd]

I have implemented your requested changes.

[stefano-m]

Thanks for your contribution. Resolved by a782e2fbb9