Jeff, The idea was that the hub should publish Atom entries and only Atom entries. Of course, the entries would contain atom.source elements to show the feeds with which they were associated. Also, the hub should do de-duping to ensure that any particular entry isn't sent more than once.
This makes sense when you consider that just about any publishing protocol is going to need some kind of either implicit or explicit "container" for a published item that combines some publishing metadata (date of update, source, etc.) with the published payload. If you see that, then you should see that Atom entries are just as useful as "containers" as just about any other format or framing mechanism. Additionally, Atom entries provide, in a standardized format, the most common meta-data that you'll need for any protocol (i.e. various dates, a unique id, and a "title" that can be used to display the thing even if you don't know how to read the payload. An optional summary is provided so that you can publish textual versions of objects that otherwise might require some difficult processing -- i.e. you can say "4.5 magnitude earthquake in San Francisco" in the summary but pass a content payload that includes all sorts of latitude/longitude data as well as geeky numerical data in the form of floats and integers that only an Earthquake processor would understand.) For me, Atom was never about "blogging"... It was a format for posting atomic units of information the Internet in a consistent manner so that a variety of applications could be built. Blogging was a minimal requirement, however, much more needed to be supported. The problem, of course, is that people tended to see Atom as just another format for RSS and haven't really pushed its application beyond the blogging case. I think that is unfortunate. The reality is that Atom entries provide a general container for published data and Atom Feeds are just one way to bundle many of them together into a single package. > I guess you would still need to subscribe to an endpoint that would emit a collection of entries Sure. But, you shouldn't be limited to the case of having to "follow" a particular feed. There should also be mechanisms to allow you to "track" across a bundle of feeds or in a firehose of feeds to select items based on their content -- not just their author or source. For instance, you should be able to say any of the following: - "Tell me whenever an entry is a blogging entry and contains the word 'foobar'" - "Tell me whenever an Earthquake happens within 50 miles of my home." - "Tell me whenever an 'offer-to-sell' tickets to a Madonna concert near New York appears." - etc. We could build all the above things very easily based on systems that publish Atom feeds and allow content-based (query-based) subscriptions. bob wyman On Mon, Nov 28, 2011 at 6:33 PM, Julien Genestoux < [email protected]> wrote: > Jeff, do you think you could help getting the folks at GitHub, Twilio, > FreshBooks, Pusher to come in here and participate? What would they love to > see in and out of PubSubHubbub so that it fits their needs? > > Bob, that's an interesting point. You said you wanted PSHB to be about > entries rather than feeds. I'm not sure I understand this. I guess you > would still need to subscribe to an endpoint that would emit a collection > of entries, right? > > Julien > > > > On Tue, Nov 29, 2011 at 12:16 AM, Bob Wyman <[email protected]> wrote: > >> On Mon, Nov 28, 2011 at 5:31 PM, Julien <[email protected]> >> wrote: >> >> > PubSubHubbub is currently too >> > much oriented toward data feeds >> Personally, I think that PSHB "went wrong" when folk insisted that it >> support RSS instead of just Atom. In the Atom format we had gone to great >> trouble to ensure that "entry" was a top-level item and that entries had >> the same semantics whether they were inside feeds or on their own. (Not the >> case with RSS.) One of the reasons that I worked to make this the case was >> that I've been wanting to do pubsub with arbitrary content for many >> years... The idea was that an Atom entry is a reasonable wrapper or >> container for just about any content you might want to publish. (MIME types >> distinguish the content type.) Thus, a system for syndicating Atom entries >> could be used to reasonably syndicate just about anything. But, when >> support for RSS feeds came into the PSHB spec, all sorts of things got >> confused... PSHB should have been about the entries, not the feeds... >> >> bob wyman >> >> >> >> On Mon, Nov 28, 2011 at 5:31 PM, Julien <[email protected]>wrote: >> >>> Jeff, thanks for sharing so quickly :) >>> I perfectly agree and acknowledge that PubSubHubbub is currently too >>> much oriented toward data feeds, and content in general, while it's >>> just a sub-case. >>> I also think the "realtime" aspect of things doesn't matter that much, >>> and is just a consequence of the "push" design. When you trigger >>> events, there is no reason to do it later than sooner. >>> >>> The spec should evolve in something that works as well for events than >>> for content. >>> It should be "subscribe to a web resource, get events". [this can be >>> decorated in any way people want to work with feeds, with publisher/ >>> hubs merged or distinct, with no data... etc.] >>> >>> Julien >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Nov 28, 11:21 pm, Jeff Lindsay <[email protected]> wrote: >>> > On Mon, Nov 28, 2011 at 2:02 PM, Julien Genestoux < >>> > >>> > [email protected]> wrote: >>> > > Jeff, please do share your feelings. Help us make PubSubHubbub >>> better! >>> > > Bob, obviously pubsubhubub should be less about blogging and/or >>> news. I >>> > > started a thread about supporting any kind of arbitrary data, and >>> this is >>> > > what I had in mind as a way to suppoty any kind of content, and any >>> type of >>> > > updates (with our without payload). >>> > >>> > To this point, my main feeling is that, yes, PSHB is focused too much >>> on >>> > content. While I think this is useful (as its been the primary use >>> case), >>> > it's not a wide enough net to really have critical mass as a project. I >>> > originally thought it was good that it was very focused and didn't >>> solve >>> > *my* particular problems. I also thought it was good it focused on a >>> > tangible goal of making feeds more realtime. However, I think time has >>> > shown it was not enough to be a big enough deal to sustain momentum as >>> a >>> > project. >>> > >>> > The problem is that this general problem PSHB solves has many different >>> > views/perspectives/languages. For example, it can be message oriented >>> and >>> > talk about pubsub. Or it can be event oriented and talk about events >>> etc >>> > (the perspective used by Phil and them). Or it can even be thought of >>> as >>> > callbacks or hooks (webhooks). There are other similar concepts with >>> > different language as well: updates/notifications, observers, etc. The >>> two >>> > main ones seem to be events vs messages/pubsub, and I'm not sure which >>> one >>> > is generally consider more general than the other. Ultimately, >>> technically, >>> > they're more or less the same thing, but I think the framing makes a >>> *big* >>> > difference. >>> > >>> > Anyway, that's the start of my ideas around this. >>> > >>> > -jeff >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > Julien >>> > >>> > > On Mon, Nov 28, 2011 at 9:33 PM, Bob Wyman <[email protected]> wrote: >>> > >>> > >> The sitehttp://www.mostlybaked.com/provides a number of quick >>> sketches >>> > >> of applications that are things that I personally think should work >>> well >>> > >> over PSHB if the focus of PSHB became less about blogging and more >>> about >>> > >> the general case of publishing and subscribing to streams of data >>> on the >>> > >> Internet. Also, Phil often talks about the kinds of things that >>> he'd like >>> > >> to do with the EventedAPI on his blog. ex: >>> > >> >>> http://www.windley.com/archives/2011/11/personal_event_networks_and_v... >>> > >>> > >> bob wyman >>> > >>> > >> On Mon, Nov 28, 2011 at 1:16 PM, Bob Wyman <[email protected]> wrote: >>> > >>> > >>> See:http://www.eventedapi.org/spec >>> > >>> > >>> As we consider what can be done to move PubSubHubbub forward, it >>> might >>> > >>> make sense to take a look at some other protocols that folk have >>> defined to >>> > >>> determine if there is anything in them that PubSubHubbub should be >>> > >>> implemented or if they do things better that PSHB does. The folk >>> at Kynetx ( >>> > >>>http://apps.kynetx.com/) have been building up a PSHB-like system >>> for >>> > >>> some time now... I'm not sure I understand why PSHB wouldn't, in >>> fact, >>> > >>> serve their needs. >>> > >>> > >>> bob wyman >>> > >>> > -- >>> > Jeff Lindsayhttp://progrium.com >>> >> >> >
