[idea] Passing of some message_sink_t to subscribe_event_handler instead of agent_t

[stiffstream]

[idea] Passing of some message_sink_t to subscribe_event_handler instead of agent_t

[ilpropheta]

I would like to drop here just a reference to a real use case we have discussed already that would benefit from this feature:
#30 (comment)

[eao197]

The idea I have at the moment is:

A new interface has to be introduced. Something like that:

class message_sink_t
{
public:
  static void
  call_push_event(
    message_sink_t & sink,
    const message_limit::control_block_t * limit,
    mbox_id_t mbox_id,
    std::type_index msg_type,
    const message_ref_t & message )
  {
    sink.push_event(limit, mbox_id, msg_type, message);
  }

protected:
  ~message_sink_t() noexcept; // Will be empty.

  virtual void
  push_event(
    const message_limit::control_block_t * limit,
    mbox_id_t mbox_id,
    std::type_index msg_type,
    const message_ref_t & message ) = 0;
};

The class agent_t will implement this interface.

A new helper class mbox_binder_t will be introduced. It will manage subscriptions between mboxes. And will destroy all remaining subscriptions in the destructor (or in a special method clear()). So a user has to create an instance of mbox_builder_t, make all subscriptions and then ensure that this mbox_builder_t lives as long as required.

Something like:

const so_5::mbox_t source_mbox = ...;
const so_5::mbox_t dest_one = ...;
const so_5::mbox_t dest_two = ...;
const so_5::mbox_t dest_three = ...;

auto binder{ std::make_unique< so_5::mbox_binder_t<> >() };

binder->from(source_mbox)
  .subscribe<MSG1>(dest_one)
  .subscribe<MSG1>(dest_two)
  .subscribe<MSG1>(dest_three);

binder->from(source_mbox)
  .subscribe<MSG2>(dest_one)
  .subscribe<MSG2>(dest_three);

binder->from(source_mbox)
  .subscribe<MSG3>(dest_one)
  .unsubscribe<MSG1>(dest_two)
  .unsubscribe_all(dest_three);

... // binder should be stored somewhere.

Where mbox_binder_t can be something like (just a sketch):

template< typename Lock_Type = std::mutex >
class mbox_binder_t {
  ... // Some internals.
public:
  class performer_t {
    mbox_binder_t & m_binder;
    mbox_t m_source;
    performer_t(mbox_binder_t & binder, mbox_t source) : m_binder{binder}, m_source{std::move(source)} {}
  public:
    template<typename Msg_Type>
    performer_t &
    subscribe(const mbox_t & dest) {
      m_binder.make_subscription<Msg_Type>(m_source, dest);
      return *this;
    }

    template<typename Msg_Type>
    performer_t &
    unsubscribe(const mbox_t & dest) {
      m_binder.drop_subscription<Msg_Type>(m_source, dest);
      return *this;
    }

    performer_t &
    unsubscribe_all(const mbox_t & dest) {
      m_binder.drop_all_subscriptions(m_source, dest);
      return *this;
    }
  };

  [[nodiscard]] performer_t
  from(const mbox_t & source) { return { *this, source }; }

private:
  ... // Implementation of make_subscription, drop_subscription, drop_all_subscriptions.
};

The implementation of mbox_binder_t will hide an actual implementation of message_sink_t interface from a user. But it seems that this implementation of message_sink_t will be very simple. The mbox_binder_t itself it expected to be more complex.

This will cover all cases when we want to subscribe a destination mbox to a source mbox (and have to possibility to use something from so5extra as the source mbox).

If a user wants to cover other use cases where a custom message sink is necessary he/she has to deal will all that stuff (like handling of subscriptions) to him/herself.

[eao197]

Implemented in v.5.8.0