tag:blogger.com,1999:blog-3376075.post109324236717917948..comments2020-11-21T01:49:14.018-08:00Comments on Kinetic: Blogs, pubsub and Web CollectionsMike Dierkenhttp://www.blogger.com/profile/02406913273929110651noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3376075.post-1093364552827312622004-08-24T09:22:00.000-07:002004-08-24T09:22:00.000-07:00Thanks for the long post on PubSub, etc... I'm gla...Thanks for the long post on PubSub, etc... I'm glad that we've built something interesting enough to motivate such a detailed analysis! However, I think you've missed a few important points about what we do.<br /><br />You wrote: "Even though pubsub.com talks about publish/subscribe technology, there isn't any 'publish' in their technology." The "publish" stuff is certainly in our technology. What we haven't done yet is expose it very widely. Currently, it is only used by our internal processes and the systems of a few select publishers. In the future, we'll be exposing it. Currently, we support (internally) publishing via REST, SOAP, XML-RPC, or over XMPP. External publishers access these publishing interfaces indirectly by posting things in their blogs or by pinging using XML-RPC...<br /><br />On REST: "REST" architectures are, unfortunately, not very useful when it comes to providing notification -- which is one of the key features of PubSub.com. We've learned this the hard way by implementing a REST API and then seeing almost everyone that used it complain that they couldn't get notifications through firewalls or that they could only get notifications sent to servers on the open net but not to their desk-top client programs. That was a major motivator behind our adoption of the XMPP XML streaming protocol. Since it relies on persistent connections it allows us to pass through firewalls and reach the desktop. Using XMPP, we can deliver notifications to the desktop using an IETF standard protocol. Using REST, we can't.<br /><br />There is a big difference between the files that you retrieve from PubSub and those that you get from Technorati or Feedster or Google (If Google supported results in RSS/Atom). The difference is that the PubSub files are static files which are updated when data arrives rather than generated on-the-fly in response to a query. The PubSub approach is massively more scalable since the amount of work that we need to do to respond to any request is tiny -- all we do is feed the file to you. This is different from other systems that do a tremendous amount of work whenever they get polled by a client -- they execute the search again. Basically, by constantly working on behalf of the customer, we avoid any need for "burst" processing. The result is a much, much smoother and predictable resource consumption profile.<br /><br />Thanks for taking the time to think about what we do, I hope the comments are useful.<br /><br /> bob wyman<br /> CTO, PubSub Concepts, Inc.<br /> http://bobwyman.pubsub.com/Anonymoushttps://www.blogger.com/profile/09394365216950330549noreply@blogger.com