Thoughts on the Bus

[wobww]

Publish/Publish Multiple

I think we can tighten up the bus api by just removing the publish_multiple method.

I found this api not very intuitive:

local Bus = require 'bus'

local new_msg = Bus.new_msg

-- Publish a single message
connection:publish(new_msg({"foo", "bar", "fizz"}, "Hello World!", { retained = true }))

-- Publish multiple messages from a nested payload
connection:publish_multiple({"foo"}, {
    bar = {
        fizz = "Hello World!",
        buzz = "Another Message"
    }
}, { retained = false })

When you compare these two methods, it's a bit confusing, what are the different arguments for?

• In publish the subtopic is a part of the message object which is passed as the first and only argument.
• But publish_multiple takes just the subtopic as it's first arg? But then also takes another object as it's second argument?
  What is this second argument for? It's not a message? Am I sending "Hello World!" -> foo.bar.fizz and "Another Message" -> foo.bar.buzz?

Also it looks like the publish method allows me to send anything as a payload, while publish_multiple might make it tricky to send a table as a payload since it uses the table keys to infer the subtopic.

Also as a user of the bus, I think it's just simpler to have one method of publishing onto the bus. I'd imagine that to publish multiple messages, I would just call publish multiple times. Don't give me too many options!

Subtopic Strings

I'd be interested to know why we landed on using subtopic as a table rather than a string.
{ 'hal', 'capability', '+', '+', 'control', '+' } is a bit long to write compared to hal.capability++control+.

Also it would be great if you can see which services are publishing/subscribing to different subtopics by doing a search on the subtopic.

next_msg api

I'm wondering whether we could make the api simpler again, by exposing less ways to get the next message, we currently have:

function Subscription:next_msg_op(timeout) end
function Subscription:next_msg(timeout) end
function Subscription:next_msg_with_context_op(ctx) end
function Subscription:next_msg_with_context(context) end

Can we maybe simplify this and just have one next_msg method, the user then works out how to combine with timeouts/cancellations.

Request/Response

When we think of a bus, we don't really think of request/response so I'm not sure whether it should be a part of the bus's api.

Could request/response instead be up to the users of the bus? If service A and service B want to chat then they can work out their own way of responding to each other over the bus.