OK, so this case seems to me to be a feed - you subscribe to a topic which generates 'things' that are separate from the topic itself. It's annoying that everybody is re-inventing feeds with new syntax, but how many of these are we really going to see before somebody defines a common minimal base?
The base for JSON could be as simple as having predefined and optional 'guid' and 'updated' fields. On Feb 25, 2011 11:06 PM, "Jeff Lindsay" <[email protected]> wrote: >> 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
