Open eao197 opened 3 years ago
There is an underwater rock here. The information about subscriptions is stored in two places:
For example, an agent can make three subscriptions to a message of type T
from mbox M
in different states. There will be three entries about type T
in agent's subscription storage. But only one entry inside the mbox M
: this entry tells M
that there is a receiver for messages of type T
.
If we have the following message type hierarchy:
image_base
`- image_vendor_A
`- image_vendor_B
`- image_vendor_C
and some agent makes a subscription for image_vendor_A
and image_base
from mbox M
then there will be two entries in the mbox M
: one for image_vendor_A
and another for image_base
. But there won't be any entries for image_vendor_B
or image_vendor_C
.
So if someone sends an instance of image_vendor_B
to the mbox M
then this instance will be ignored because there is no entries for such type in the mbox M
.
Hi! I resume this old issue (motivated by #24). Do you have any ideas if this can be implemented somehow in the future? I think that matching rules similar to exception handers would be aligned with C++ semantics and can simply users' understanding.
Hi! I made several attempts to solve this problem in the past, but didn't found a solution.
So, maybe it's time to make a new attempt... :)
Awesome! If I can be helpful, don't hesitate to let me know (maybe for some feedback on the possible interface and trade-offs)!
A question that have never been asked earlier:
There are not only event handlers, but also delivery filters, message limits and message sinks (with transformers or something else) that are also bound to message types. Should things support inheritance too?
For example, let's assume there is an agent:
class demo_handler final : public so_5::agent_t
{
void so_define_agent() override {
so_set_delivery_filter(source_mbox, [](const image_base & msg) { ... });
so_subscribe(source_mbox)
.event([](const image_vendor_A & msg) {...})
.event([](const image_vendor_B & msg) {...})
;
}
};
Should the delivery filter for image_base
receive messages of image_vendor_A
and image_vendor_B
?
Another example:
so_5::single_sink_binding binding;
binding.bind<image_base>(source_mbox, so_5::wrap_to_msink(dest_mbox));
so_5::send<image_vendor_A>(source_mbox, ...);
so_5::send<image_vendor_B>(source_mbox, ...);
...
Should such a binding redirects image_vendor_A
and image_vendor_B
to the dest_mbox?
And a more complex case with delivery_filters.
Let's imagine a hierarchy:
image_base
`- image_vendor_A
`- image_bgr_base
`- image_vendor_B
`- image_vendor_C
And potential so_define_agent
:
void some_handler::so_define_agent() {
so_set_delivery_filter(source_mbox, [](const image_base &) {...});
so_set_delivery_filter(source_mbox, [](const image_bgr_base &) {...});
so_subscribe(source_mbox)
.event([](const image_vendor_B &) {...})
.event([](const image_bgr_base &) {...})
.event([](const image_vendor_A &) {...})
.event([](const image_base &) {...})
;
}
I can imagine that such double (or triple, or quadruple, or ...) filtering might be necessary and should be enabled. But I afraid it would make implementation of custom mboxes much harder.
There is another idea of how this issue can be resolved: https://github.com/Stiffstream/sobjectizer/discussions/82
NOTE. This issue is just a reminder that SObjectizer needs a solution for use-cases like described in #24 I don't know how and when this will be implemented (and can it be implemented at all), but the reminder will help to form scope for a new SObjectizer's release when appropriate resources will be available.
The task is to allow writing something like that:
Additional requirement. It'll be great to have that functionality for handling messages from mchains too: