Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A way for a message to be filtered #23

Open
mattisking opened this issue Jul 22, 2019 · 2 comments
Open

A way for a message to be filtered #23

mattisking opened this issue Jul 22, 2019 · 2 comments

Comments

@mattisking
Copy link

This is great and I handle the filtering in the subscriber currently, but it would be cool if I had a way to Subscribe to an object, but only if that object has a certain key value. In RabbitMQ I can accomplish it with different channels. Basically I have an object being emitted from a background processor reading from an open socket, completing messages, serializing them as needed, filtering out things that aren't necessary, etc and then eventing/emitting the message out. The message itself is a consistent json payload and I've been experimenting with having that process Publish the Message and then my Consumer objects Subscribe and then each can process that payload however. The only issue is that each of my consumers cares about only payloads that meet certain criteria (generally a single identifier field in the json payload). Currently I just send down all the messages to all the consumers and they filter them as needed, but it would be cool if I could somehow specify in the consumer which payload I want when subscribing. I can't use RabbitMQ or Redis PubSub in this application and was looking for a simple in-memory pubsub mechanism and this has been great.

@upta
Copy link
Owner

upta commented Jul 23, 2019

Hmm, that's an interesting thought. I definitely want to keep a pretty simple, straight-forward pattern but something along those lines wouldn't be too bad of a feature creep I don't think.

Initial, off-the-cuff thought would be overloads to Publish/Subscribe that take a "channel" string and registrations become a combination of Type + channel.

One thing I'm not sure of at the moment is if it would be better to have the channel-less Publish go to every subscription of the Type (basically how it works right now), or if they should basically just go into their own "default" channel.

Doing it based off a property of the Type would be doable as well, though it would require Type to implement an interface. Could allow for some more dynamic scenarios than the pure channels path, though will add a bit more complexity for using it.

@DavidRMaltby
Copy link

DavidRMaltby commented Jul 30, 2019

Personally, I would keep it simple and left up to the subscriber to determine the filtering. I wouldn't force a "channel" string into the design.

For instance, I would overload the Subscribe method like so..

public void Subscribe<T>( object subscriber, Action<T> handler, Func<T, bool> filter)

When Handler instances are tested in Hub.cs Publish() method with...

handler.Type.GetTypeInfo().IsAssignableFrom( typeof( T ).GetTypeInfo() )

Then in addition to that clause, if it isn't Null, then call a new Filter property in the Handler instance to see if the Subscriber wants it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants