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? -- John Panzer / Google [email protected] / abstractioneer.org <http://www.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 >
