> So the provider certainly knows the format; the consumer better (how else is > it going to parse it?); that leaves the hub. > In the case of "one thing which mutates" is there a need for a guid beyond > the url of the thing itself?
The thing being the entry/event/payload? If you're doing arbitrary content, such as to represent an event, there may *not* be a URL associated with it, let alone referenced in the payload. However, in the case of GitHub's post-commit hooks, there is a guid in the payload, which is a great example/case of "don't enforce a guid in PSHB for signing because the provider should/will provide their own". -jeff > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > > > On Fri, Feb 25, 2011 at 10:45 PM, Jeff Lindsay <[email protected]> wrote: >> >> > Which parts of the system (provider, hub, subscriber) need to know the >> > guid >> > and/or timestamp for each thing? >> >> I could be wrong, but the provider should either have or generate >> them, the hub *may* use them for idempotency in the case of "fat >> pings" (hate that phrase, but is the language used around here) but >> certainly doesn't need them, and then the subscriber *should* use them >> for the same reason. >> >> -jeff >> >> >> > -- >> > John Panzer / Google >> > [email protected] / abstractioneer.org / @jpanzer >> > >> > >> > On Fri, Feb 25, 2011 at 5:04 PM, Jeff Lindsay <[email protected]> >> > wrote: >> >> >> >> To summarize the problem from my understanding: Atom comes with unique >> >> IDs/dates for each entry. Arbitrary payloads would have to put it in >> >> the headers. Then signing (as proposed in the header) would have to >> >> somehow include that to be useful against replays. >> >> >> >> I thought about it and I feel like we might be able to come up with >> >> something, but, you know, if you're doing arbitrary payloads you might >> >> already have this in your body! I think the burden of putting a unique >> >> ID in your payload is much easier than telling your users they have to >> >> use HTTPS (even though I agree everybody should be using it). >> >> >> >> -jeff >> >> >> >> On Fri, Feb 25, 2011 at 2:42 PM, Brett Slatkin <[email protected]> >> >> wrote: >> >> > Good discussion. Separating distribution from semantics is a >> >> > worthwhile goal. Probably the easiest goal to achieve, too. >> >> > >> >> > I banged my head against this problem a few months ago. Where I left >> >> > off was that we need a solution to the HTTP "turducken" problem. Can >> >> > you guys go over this thread for me? >> >> > >> >> > >> >> > >> >> > http://groups.google.com/group/pubsubhubbub/browse_thread/thread/6bb4b26043059f27?pli=1 >> >> > >> >> > Am I wrong to think we even need to solve this? >> >> > >> >> > -Brett >> >> > >> >> > >> >> > On Fri, Feb 25, 2011 at 1:15 PM, Alexis Richardson >> >> > <[email protected]> >> >> > wrote: >> >> >> +1 >> >> >> >> >> >> On Fri, Feb 25, 2011 at 8:10 PM, Charl van Niekerk >> >> >> <[email protected]> wrote: >> >> >>> On Fri, 2011-02-25 at 12:02 -0800, Jeff Lindsay wrote: >> >> >>>> Yes, this is where I'm at, too. It seems like we're getting there >> >> >>>> though. It just seems like (and I could be wrong!) there is a lot >> >> >>>> of >> >> >>>> bias towards Atom/feed semantics. Even the tiniest structure is a >> >> >>>> constraint to use cases and adoption. That's all I'm saying. Also >> >> >>>> just >> >> >>>> the marketing. Is it about feeds or is it a distribution >> >> >>>> framework? >> >> >>>> Because it sounds like the former and that's what people think >> >> >>>> that I >> >> >>>> talk to and they decide it's not worth messing with. >> >> >>> >> >> >>> Same here, Atom feeds were obviously the most logical place to >> >> >>> start >> >> >>> and >> >> >>> would have the greatest short-term impact on the web as it stands >> >> >>> but >> >> >>> to >> >> >>> have to reinvent the wheel for other formats is kinda ridiculous. >> >> >>> Would >> >> >>> be awesome to see PubSubHubbub become a more generic distribution >> >> >>> framework and be marketed as such! >> >> >>> >> >> >>> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Jeff Lindsay >> >> http://progrium.com >> > >> > >> >> >> >> -- >> Jeff Lindsay >> http://progrium.com > > -- Jeff Lindsay http://progrium.com
