Publish Subscriber Pattern in Qt

[caduel]

just use signals & slots across threads (Qt4)

[donglebob]

But this is Observer what you mean.

What I have implemented is the following:
My Publisher gets data from external,...checks the content and sends this data to the right subscriber.
When the content of the data includes an information to broadcast the incoming data.
It broadcast it to all subscribers.
When a subscriber is not known my publisher creates a new subscriber (thread).

I think that this is not Observer. Observer pattern sends every time the incoming data to all subscribers, without checking the content.

I think that what I made is the content-based Publish Subscriber model.
But I am not sure if this is the right name for it....I need to define it in my thesis.

Can someone give me a hint?

[donglebob]

I think I mixed there something.

There is a publisher/subscriber design pattern and a publish/subscribe messaging model.
http://en.wikipedia.org/wiki/Publish/subscribe

What I mean is not the design pattern...

[caduel]

Well, if you want to send the data only to *some* of the subscribers, then a signal won't do the job. (Which is too bad, since a signal would have solved all threading issues.)

In this case you have to check the "message" (inside the publisher) for each subscriber. This is easy since it does not have to do with threads.
Once you know if a specific publisher gets the message, you "just" send him the message. This is the interesting part. There are various possibilites:
* post an event to the receiving object (posting events in QCoreApplication is thread safe)
* have all subscribers provide a thread-safe callback
* there certainly are more ways to do that...

The 'right' choice depends on your concrete requirements.

HTH

[donglebob]

Thats what I have done already.
I send the data after analyzing it. The data has something like a destination address.
With this address I can look into a list and get the pointer to the right receiving thread.

With this information I can connect my sending signal from the publisher with the slot of the subscriber. And send the data....
This procedure will be repeated for every data received.

This way of providing data to the subscribers looks similar to the "publish/subscriber messaging model"
But in my case there is one difference....my publisher creates the subscribers itself..and that means he registers them.

My question is now...can I call what I did publish/subscriber messaging or not?
Or is this another kind of messaging model?

[donglebob]

Anyone out there who can give me a hint?

[rwtmoore@hotmail.com]

I'm not 100% sure of what you're doing, but I may know enough to be helpful.

I think what you are doing is pub/sub; I don't think it matters who creates the subs.

I don't know the particulars of your subs. Do you know the max number? Do you know the names of the objects ahead of time?

If the answer to the above 2 questions is yes, I can suggest something.

Let's say you have 3 objects that can subscribe to a publisher. Or put another way, 3 slots that can possibly be connected to a signal. That means there are 7 possible combinations. That means you can have 7 signals each with their own corresponding connect to a slot or slots.

bool QObject::connect(ptrPublisher, SIGNAL(Signal_1(), ptrSubscriber, SLOT(Slot_1() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_2(), ptrSubscriber, SLOT(Slot_2() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_3(), ptrSubscriber, SLOT(Slot_3() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_4(), ptrSubscriber, SLOT(Slot_1() );
bool QObject::connect(ptrPublisher, SIGNAL(Signal_4(), ptrSubscriber, SLOT(Slot_2() );

etc.


Possible slots: (1), (2), (3), (1,2), (1,3), (2,3), (1,2,3)


How you determine which slots are to be connected is up to you (if-else, switch statement, etc.)

When you determine which slots are to be connected, just emit the appropriate signal.

[d_stranz]

I'm sure this answer was very helpful, seeing as how you posted it over 4 years after the original thread was started.

[rwtmoore@hotmail.com]

I know at least one person read it...