1

I have a project that uses wx pubsub heavily to communicate to various parts of the code. For any given message, it could be of interest to 1 to 5 different subscribers.

In a previous version of the code, I had a very large dictionary of listeners that looked something like:

{"SENSOR_FLIP": "SENSOR FLIPPED",
 "ALARM_TRIGGERED": "ALARM TRIGGERED",
 etc}

and I would subscribe in the various portions in the code that were interested in those events. The problem started when the code started getting large and there were lists of subscribes in the inits of most objects. It was unwieldy and became an issue of making it difficult to ever change anything about the messages or knowing what was receiving what.

So then I tried standardizing messages to 3 types: TASK, INFORM, and STATUS with an identifier at the beginning to show who sent it (a generalized identifier, so it would send "sensor STATUS" rather than "sensor 17 STATUS". I then subscribed to the general areas I was interested in and let the listener sort through if it was actually interested or not. The problem arose here with the signal "interface TASK" -- there were a bunch and I had every sensor, station, service, alarm, light, etc in the entire system grabbing them and sorting through.

Is there a better way to organize this? All I can think of is going back to specific naming of signals and a group of lists in config that flesh-out what each object is interested in, then doing a map subscribe at the init of each object to each thing in its list.

Any ideas on how to do it better?

linus72982
  • 1,418
  • 2
  • 16
  • 31

2 Answers2

1

You are not using pubsub as intended. The concept of publish/subscribe is to reduce the coupling between the producers of events (publishers) and the clients (subscribers). In the pubsub paradigm the publisher is not supposed to know who the subscribers are, or what they are doing with the signals. When you make a "large dictionary of listeners" and when you say it became difficult to know "what was receiving what" it indicates that you are trying to re-couple the individual modules. I don't understand what problem you are trying to solve, but in any case it sounds like pubsub is the wrong tool for you, or perhaps you haven't bought into how to use it.

Also you remark that it's hard to modify the message details once they are put in place. Of course it is! If you want to change a message and there are already 100 clients, you have to grep all 100 of those places and see what kind of damage your change will cause. How can there possibly be a way of avoiding that? Perhaps it's better to add new messages rather than modify old ones.

The idea of having only three message types and then requiring all the clients to sift through a bunch of junk to find the ones they're interested in sounds like a terrible idea. Again it seems like you haven't embraced the pubsub concept.

Paul Cornelius
  • 9,245
  • 1
  • 15
  • 24
  • I didn't explain well. I am not allowing senders to know about receivers, I'm talking about organizing it while I'm building. I can't ever remember the format of the message sent or what I named the args or what I named the signal, etc. I also have tons of subscribe lines at the top of classes to grab messages instead of being able to do things like map() on a bunch at once if I had a standard naming convention. That's the kind of thing I was talking about. In the last few hours I figured out a good way to format the message names that makes it easy to subscribe in bundle if need be. – linus72982 Apr 21 '15 at 00:45
  • For example, I have 5 different services that send out status -- what do I call the signal? I used to have signals like "SYSTEM_STATUS_SEND" and then I'd later add one that looked like "ALL_SERVICE_STATUS_GOOD" -- there was no standard. Also, sometimes I'd send the arguments as message=, sometimes it would be object=, etc -- I could never remember what the arg name was. I now came up with : -- so I have messages now that look like "DETECTED_ELEMENT_SENSOR_OPEN" and all send message=, now I can subscribe to messages in a standard way – linus72982 Apr 21 '15 at 00:51
0

I was scratching my head over the same problem, and it turns out the answer is already in the Pypubsub package, here:

https://pypubsub.readthedocs.io/en/v4.0.3/usage/usage_advanced_maintain.html

In a nutshell, it enables you to specify a "topic definition tree", which lays out the topic names and sub-names hierarchy, and the names of the required and optional arguments for each topic.

Now I have a neat and well defined set of topics to operate with. Thanks Pypubsub!

Douglas Warner
  • 1
  • 1