Dave Cridland <[email protected]> wrote: > given that much of the information in the Atom > portion is static and not actually related to this > message, per-se, *can't it be requested on demand*? (emphasis added)
What you are suggesting is a move from a "data publishing" model to a "notification" model. This is often (when talking about blogging stuff) discussed as the difference between "fat pings" and "light pings"... For some in-depth discussion of the difference between the two models, check out this page on the PubSubHubbub site: http://code.google.com/p/pubsubhubbub/wiki/ComparingProtocols (There is detailed discussion below the chart. Scroll down...) You'll see that there are serious problems with the "light ping" or "notifications" model that you suggest. These problems begin to seriously impact the scalability of the overall system once it grows beyond very light traffic loads. We have many years of very nasty experience with the "thundering herd" problems that can result from using light pings in popular distributed systems. Please do not regress to the old, now largely deprecated, light pinging/notification model. That stuff works great in small systems or in prototype demonstrations, but it is a real mistake for any system that expects to experience successful growth. bob wyman On Thu, Apr 29, 2010 at 12:29 PM, Dave Cridland <[email protected]> wrote: > On Thu Apr 29 17:20:36 2010, bear wrote: > >> I'm not talking about server side issues - the server should pass the >> Atom portion on to the client just like it does everything else. >> >> The *client* tho should be able to handle Atom and create a >> displayable item from the Atom - it requires similar parsing issues as >> XHTML-IM IMO >> >> >> Well... leaving aside for a moment whether clients should understand Atom > for other reasons, it strikes me that given that much of the information in > the Atom portion is static and not actually related to this message, per-se, > can't it be requested on demand? And doesn't this entire thing start to > suggest that really, OMB/XMPP should be using something more complex for > "willing participants", as compared to just bombarding clients with Atom? > > I mean - yes, absolutely, support naïve clients which haven't the faintest > idea they're talking to an OMB service, but I don't see those as likely to > understand all the Atom blurb anyway. Oh the other hand, if a client *knows* > about "OMB/XMPP", it can do clever stuff, and keep itself updated with all > the profile data it needs without it being sent continuously with every > message, and therefore doesn't need the full Atom blurb... > > > > But what Kevin suggests in his reply I suspect is the real answer - >> the Identica bot should grok client capabilities and not send all the >> stuff in the first place. >> >> >> Right - but what about when clients are offline? Is it a case of > last-known-state wins? The trouble being we're assuming the last case will > be the next - if you're alternating between Atom/XHTML-IM aware client and > a non-aware, maybe mobile, client, you'll be gettign precisely the wrong > behaviour. > > > Dave. > -- > Dave Cridland - mailto:[email protected] - > xmpp:[email protected]<xmpp%[email protected]> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
