Dispatcher is not an event broker dependency

[mpraglowski]

No description provided.

[paneq]

this is constant :( please don't

[paneq]

this is always a new, separate instance, initialized for every new client. no accidentally shared dependencies.

[paneq]

step in a good direction, i wonder if we could not pass self instead of event_broker, dispatcher.

[paneq]

probably not.

[mpraglowski]

Nope. We do not have thread subscribers in client, we need a broker here (and dispatcher too). We might have get this from client but they are protected and exposing this outside client is not good.

[paneq]

is Broker still actually a broker if it does not handle dispatching the events?

[paneq]

I know it was my idea, but I don't think I am particularly happy with the end result.

I was not happy with broker taking dispatcher as a dependency. I am not so happy with client orchestrating the broker&dispatcher flows either. I think we are missing a 3rd option.

I think we need a new class that takes Dispatcher and Broker as dependencies. And since broker no longer deals with dispatching, I believe it should be named differently. It's more like a... list of subscribers, list of handlers, ... handlers register, observers ? This new class would basically implement a pub/sub. I think the API would be that of current Broker.

Hmmm, I think that basically means. Instead of doing all that we did here. Let's extract those 4 methods from Broker as a separate class (ie register). And broker (aka pub-sub) just wires these 2 dependencies together.

class Client
  def initialize(dispatcher:, register:, ...)
    @broker = EventBroker.new(dispatcher, register)
  end

• dispatcher - knows how to call sync/async/whatever handlers that subscribed/registered for certain events
• register - keeps a querable list of who subscribed for what.
• broker - a facade for both. A full pub/sub implementation. Might even be called PubSub :)

What do you think?

[mpraglowski]

It makes sense. We will have 3 classes.

Dispatcher - responsible for dispatching events to subscribers
Subscriber - responsible for managing subscriptions
Broker - "just" a pub sub - this will have both 2 previous ones given as dependency and will do the notifications - the code from client to notify subscribers should go there

[paneq]

@mpraglowski exactly.

I am not sure about the names though:

Dispatcher - mkay
Subscriber - is it really a subscriber? We call a subscriber the thing that subscribes (handlers), not the thing that keeps a list of subscriptions.
Broker - mkay

I was even thinking about

• pub
• sub
• PubSub.new(pub, sub)

😂

Feel free to come up with anything you feel good about.

[mostlyobvious]

no deprecations for this change?