Same for me, I think Jeff's points about simplicity and single-purpose are in line with what I'd want. the only thing I want to make sure is that whatever direction the protocol takes doesn't make assumption as for the data type and won't exclude anything.
Julien On Tue, Nov 29, 2011 at 2:51 AM, Alexis Richardson <[email protected]>wrote: > +1 > > I get Atom for metadata here, but agree with Jeff's main point. > > > On Mon, Nov 28, 2011 at 7:45 PM, Jeff Lindsay <[email protected]> wrote: > >> 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. > > > > Yeah, I get the reasoning behind Atom and I understand it's more general > > use. The problem is in order to make something useful and easy to adopt, > you > > need to really facilitate what people are already doing and are familiar > > with. Not everybody wants to work with Atom, despite all its benefits. > > Having Atom as a representation or as a possible payload is great, but > > depending on its semantics, forcing it to be required for PSHB to be > useful > > is not a great idea... or least a pragmatic one IMO. > > > >> > >> We could build all the above things very easily based on systems that > >> publish Atom feeds and allow content-based (query-based) subscriptions. > > > > Call me crazy, but I'm in love with the Unix philosophy of doing one > thing > > well and designing for composition of more complex systems from simple > > parts. Queries and filters, to me, are out of the scope of this protocol, > > despite being very useful. The reason is that anybody can create a > > subscriber or relay (perhaps even a hub) that happens to do that > filtering > > in its implementation. > > That said, I'm assuming this was more just to defend Atom and > content-based > > subscriptions, to which I would say: those examples should be possible > *if* > > you use Atom as your content container and have access to or can build a > > subscription querier node. But it should also be possible if the content > is > > *not* Atom using the same approach of putting the filtering in an > > intermediate node (or potentially being an implementation detail of a > hub). > > I just think the core should be simple and neutral, allowing more > > specialized extensions, additions, and combinability. And for that, my > > experience (and general observations) suggest that we should focus on > > content-type neutral HTTP-based mechanisms. > > -jeff > > > >> > >> 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 > >>>> > >>> > >> > > > > > > > > -- > > Jeff Lindsay > > http://progrium.com > > >
