I think those words are unfortunate and should be changed. This blog post is perhaps a clearer description of how I see the relationship between PuSH and Evented APIs. http://www.windley.com/archives/2011/12/apis_that_call_you.shtml Something that doesn't come through in the spec doc very clearly (and needs to be updated) is the idea that Evented APIs are almost always one-to-one, meaning that the event is being raised on behalf of an entity. Think of connecting your account at Fitbit with your account at Withings. I want Withings to know when there's new Fitbit data. --phil-- Phillip J. Windley, Ph.D.www.windley.comwww.kynetx.com=windley
On Dec 12, 5:19 pm, Ka-Ping Yee <[email protected]> wrote: > Hi Sam and Phillip, > > I'm curious about the Evented APIs spec and am trying to understand what > motivated it. I noticed this answer to the FAQ about PubSubHubbub, but it > didn't really help: > > The complexity of using a distribution hub doesn’t make sense for anything > but large systems. PuSH was a way to reduce polling on the origin server, > but it’s really a stop-gap for better evented systems. > > "PuSH is just a stop-gap" seems like a content-free answer. I imagine you > must have had more detailed reasons in mind; would you mind elaborating a > bit on what you mean by "stop-gap" and "better"? > > Thanks, > > —Ka-Ping Yee
