Changed client creation interface

[martenjacobs]

Replaced dbus.systemBus() and dbus.sessionBus() with dbus.connect({bus: "system"}) and dbus.connect({bus: "session"}), respectively, as discussed in #23

[acrisci]

Actually I'm thinking we can get rid of the convenience function completely to make things even simpler.

I like how the postgres client does it.

const { Client } = require('pg')
const client = new Client()

await client.connect()

Which would look like this for us:

const { MessageBus } = require('dbus-next');
let bus = MessageBus();
// calling connect is optional, but there is a use case to wait for a connection
await bus.connect();

What do you think about that?

Also we should default to the session bus and have an enum for the bus type.

[martenjacobs]

// calling connect is optional, but there is a use case to wait for a connection

Do you mean this would cause the first call on the bus to first wait for the connection?

[martenjacobs]

let bus = MessageBus();

I suppose we'd put our options in the MessageBus constructor? Could you elaborate how you think this should look?

[acrisci]

Do you mean this would cause the first call on the bus to first wait for the connection?

Yes, this happens anyway though. The connection is complete after the "Hello" method is called on the org.freedesktop.DBus interface to give us a unique name. We buffer any messages before that time and send them in a batch after connection is complete. The bus will connect in the constructor, but awaiting a connection just makes it more explicit. Right now, the bus has a "connect" event for that purpose, but I think awaiting is better.

I suppose we'd put our options in the MessageBus constructor? Could you elaborate how you think this should look?

Yeah something like

let bus = MessageBus({ busType: BUS_TYPE_SYSTEM, authMethods: ['ANONYMOUS'] });

[martenjacobs]

Right now, the bus has a "connect" event for that purpose, but I think awaiting is better.

I agree, it's much clearer to the user

---

Yeah something like

let bus = MessageBus({ busType: BUS_TYPE_SYSTEM, authMethods: ['ANONYMOUS'] });

I do think we need support for custom bus URIs (because I'm using it :) ), so perhaps this would be better:

let localBus = MessageBus({ bus: BUS_SYSTEM, authMethods: ['ANONYMOUS'] });
let remoteBus = MessageBus({ bus: "tcp:host=remote_host,port=1234", authMethods: ['ANONYMOUS'] });

I think busType is kind of a weird name, as the buses (busses?) themselves don't really differ, other than the services connected to them on the other side. I think just using the word bus would be clearer. That way, we could also let the user supply a URI instead of a well-known bus through the same key

[acrisci]

I don't want to document this because I think I want to change it to pass authenticator classes instead of strings.

[acrisci]

I think busType is kind of a weird name, as the buses (busses?) themselves don't really differ, other than the services connected to them on the other side.

Practically, the difference is how the address is found. There is a different way of finding the address per type and that's what's being expressed by the busType. The busAddress is derived from the type and can be different based on what user session is currently running. You should not use an explicit address in public code because users may want to set this themselves with environment variables.

That way, we could also let the user supply a URI instead of a well-known bus through the same key

In general, the busAddress option is something I don't want people to use at all. I might even remove it until someone comes up with a proper use case for it. So I think it should be a separate key to indicate it's a weird option.

In your case, you should be doing this to indicate the address:

DBUS_SYSTEM_BUS_ADDRESS="tcp:path=address" ./my-script.js

[acrisci]

Taking a look at it again, I think this change might be a bit too much of a change for the benefit. Maybe we can revisit it later.