Talk:Publish–subscribe pattern

message: *I'm removing the following paragraph from the "Disadvantages" section.  Broadcasting or multicasting messages does not typically lead to greater network load than traditional client/server (which normally uses Unicast).  For any given volume of messages, broadcast or multicast will almost always lead to less network load than unicast since unicast-based systems must transmit a separate copy of each message to each subscriber.  The whole point of multicast is to prevent this duplication of data.  Perhaps the author was thinking of UDP or raw IP v.s. TCP.  Most UDP or raw IP protocols do not have the sophisticated congestion control that TCP does.  TCP will automatically slow down publishers to prevent network overload, whereas UDP protocols will not.  Since broadcast and multicast protocols always UDP or raw IP, it might be easy to blame the addressing mode for the lack of congestion control.  I thought about simply re-working the paragraph to reference UDP and raw IP, but the problem of network overload is far from universal even there.  Some multicast pub/sub systems offer other methods of congestion control, such as rate limiters.  In reality, network overload is a characteristic of individual implementations of pub/sub, not of the paradigm, addressing method, or underlying protocol.  Here is the original paragraph I'm removing.  Fordsfords 03:23, 11 March 2007 (UTC)
replies: text: Messages are often broadcast or multicast over a network, allowing for a more dynamic network topology.  However as the volume of messages increase, this can result in overloading of the network without appropriate management or pruning strategies.  This may be mitigated by the fact that hardware typically enjoys better economies of scale than software.
Whats the point of keeping an article on "click fraud" in the Articles section?  —Preceding unsigned comment added by 203.200.84.194 (talk) 16:05, 4 September 2007 (UTC)
thread_title:  Opening heading

message: with a number of implementations of pub/sub --Malin Randstrom (talk) 09:57, 18 August 2008 (UTC)
thread_title:  Adding a new paragraph

message: The concept sounds a lot like feeds, alerts, newsgroups... Why aren't any of these mentioned? Or is this about something completely unrelated?  —Preceding unsigned comment added by 87.162.8.17 (talk) 00:27, 28 October 2008 (UTC)
thread_title:  Real life examples? 

message: The article begins with a definition of what it's not: "Publish/subscribe (or pub/sub) is an asynchronous messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather..."
As well as being awkward to start by defining what it's not, do these other paradigms that it's being constrasted with have their own names and or articles that can be mentioned? I.e. is there a page/name for "asynchronous with specific/explicit subscribers", or "synchronous with specific/explicit subscribers" (or even "asynchronous with explicit subscribers", whatever exactly that would mean)?
The focus of the article also seems to be on networking (given the asynchronous nature), but it's linked to from places which describe it more as a general software pattern (i.e. one that might be used internally in a program). Is that actually true? If so, does it need addressing? 72.86.22.222 (talk) 03:48, 22 May 2009 (UTC)
thread_title:  Contrast with explicit subscribers, synchronous 

message: The article, "Publish/subscribe," has a box saying the article, "Observer pattern," should be merged into it. Event listener has been made into a redirect to observer pattern. Event pattern currently does not exist but is synonym for observer pattern from what I see. Event patterns and event listerners are closely related and currently link to event handlers, which has a box saying it should be merged into event (computing). Event handlers are also currently  covered in depth in Event-driven programming.
Additionally, a few articles that link to event handler are up for merging: Event cascade, event model, Event notification. The event notification article says it is "sometimes a synonym for Publish/subscribe."
All of the articles are relatively small on content, and together, they already contain a lot of redundant information. I believe all of these articles cover bits and pieces of one concept that could be explained a lot better if they were merged into one article. What is everyone else's thoughts? I may be wrong on including some of the articles on here, correct me if I'm wrong, but I don't feel 8 small articles are needed if they share the same ideas or are pieces of one idea.
Article                 	Google Hits	# of Wiki articles linked to it	Merge requested	Article size
event (computing)       	?          	41                             	-              	3,256
event handler           	1,137k     	48                             	Yes            	3,015
event notification      	618k       	1                              	Yes            	1,427
publish/subscribe       	225k       	39                             	-              	11,005
event model             	216k       	3                              	Yes            	1,411
event listener          	213k       	5                              	Yes            	redirect
observer pattern        	106k       	59                             	-              	9,986
event pattern           	106k       	0                              	-              	unexisting
event-driven programming	90k        	247                            	-              	10,870
event cascade           	5k         	1                              	-              	396
TOTALS                  	2,716k     	444                            	-              	41,366
Quilokos (talk) 00:04, 4 July 2009 (UTC)
thread_title:  Too many articles? 

message: Having worked for almost 10 years on publish/subscribe-related technologies including programming language support, I agree that "observer" and "publish/subscribe" should not be merged. More precisely, I think it is important to make the difference between the observer design pattern and publish/subscribe, or at least between how the observer design pattern is implemented and the latter. With the observer design pattern, observers register directly with the subject; the subject retains thus explicit references to the observers which the subject uses to notify these one after another upon an update. One of the main goals of publish/subscribe is precisely to avoid such explicit references, allowing publishers and subscribers to remain anonymous to each other. This avoidance of explicit references is key to the scalability and decoupling of the publish/subscribe paradigm. A publish/subscribe mechanism can definitely be used to achieve observer-like interaction, but not vice versa.
Note that if there is something like an observer pattern w/o "design"  then than might be closer to publish/subscribe. But then I don't know what the definition of that would be.
Patrick Eugster (talk) 1:55, 3 November 2009 (UTC)
thread_title:  Observers vs publish/subscribe 

message: What does this mean?
As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones.
99.9.120.82 (talk) 00:03, 18 August 2010 (UTC)
thread_title:  Scale? 

message: This article's intro assumes WAY too much familiarity with the field of computer software. Should at least start with something like "In software development, publish/subscribe is..." Denbosch (talk) 16:24, 13 February 2012 (UTC)
thread_title:  Intro doesn't set out context 

message: This article says that Publish/Subscribe is a messaging pattern which (I mean messaging patterns) fall under Concurrency patterns according to this article, but according to the same article Publish/Subscribe pattern itself falls under Behavioral patterns!! so, is it a Behavioral or Concurrency pattern?
Thanks in advance - Ahmad510 (talk) 11:09, 16 June 2013 (UTC)
thread_title:  Behavioral or Concurrency pattern? 

message: Is this sometimes called pub sub ? Should add to article if yes. Kotz (talk)✓ Kotz (talk) 11:10, 13 November 2016 (UTC)
thread_title:  Pub sub  

message: The disadvantages section on this doesn't make logical sense so I'm going to trim it down. Inflexible pattern? Publish/subscriber has nothing to do with that and is more of a transport mechanism. Most patterns can take free text which can be structured or unstructured.  — Preceding unsigned comment added by Namlemez (talk • contribs) 01:04, 13 June 2017 (UTC)
thread_title:  Disadvantages