Hi Monica, I think it was entirely unintentional, but the language of the proposal sometimes gives the impression of trying to replace aspects of PuSH (e.g. "backwards compatibility" in relation to discovery?).
Putting that aside, I don't see any major stumbling blocks to getting what you need. Getting generalisation of the format should be just easy - change a HTTP header and any current PuSH subscriber can swap between Atom/RSS parsing and JSON parsing with no effort at all. We still really need the original XML based hub discovery given just how feeds operate in practice, but specifying alternative means for other formats via the HTTP header does not clash with that and, from my lurking on other mailing lists besides PuSH, looks quite good. Same for light pings, though it's probably the more complex of the set in terms of adding to the specification. The others, I'll leave to wiser people than myself. I support having some authorization, but I'm unsure if it belongs in the main PuSH specification or should be rolled into an extension. I think an extension would be preferable since it makes it clear the authorization is an optional Hub element, similar to how Superfeedr, for example, uses HTTP Basic Auth. From an implementation point of view, which is more my area of knowledge, what you're seeking would be reasonably straightforward to support. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com ________________________________ From: Monica Keller <[email protected]> To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>; Activity Streams <[email protected]> Sent: Thu, May 20, 2010 7:51:42 AM Subject: Re: [pubsubhubbub] Re: deleted an published entry scenario Good point on http headers for discovery but definitely I am not asking for only JSON or for light pings... that would be a big change On May 19, 2010, at 10:29 PM, Bob Wyman <[email protected]> wrote: Monica Keller <[email protected]> wrote:> I would rather make it a little bit more generic > > >Your proposals don't just make it a "little bit more generic." What you are >doing is attempting the change fundamental attributes of the protocol. > * By arguing for notifications (light pings) instead of pushed data, > you're re-introducing all the scalability problems (like thundering herd) > that PSHB was explicitly designed to eliminate. > * By insisting on JSON, you're attempting to change a generic > server-to-server protocol that leverages XML and a decades' worth of tool > development into one that is limited to supporting a still relatively new > language-specific data format most useful for communicating with client code. > * By arguing for hub discovery via HTTP Header, you're asking for a > mechanism that can only be used by those who have administrative control over > their web servers -- which is not the case for many feed producers who use > shared or even out-dated web servers. Thus, invalidating PSHB's goal of > allowing any feed on any server to associated with a hub. >These do not seem to me what constitutes just "a little bit more generic." > > >bob wyman > > > >On Thu, May 20, 2010 at 1:12 AM, Monica Keller <[email protected]> wrote: > >Here was my reasoning >>1- PubSubHubbub is gaining momentum so I would rather make it a little bit >>more generic than dilute it's effort releasing an alternative. >>2- PubSubHubbub and Activity Streams are closely promoted and we are moving >>away from Atom being the core serialization for activity streams because it >>makes the response more complex than it needs to be... think of activities >>such as liking, rsvping to events, friending even status updates are way more >>verbose than they need to be. >>>> >>3- We have been discussing some of these changes in this community for a >>while: synchronization, authentication, http based discovery I am just >>grouping them together so we could release an iteration of the spec that >>supports a concrete use case >>>> >> >>What do you think ? >> >> >> >> >> >>On May 19, 2010, at 7:56 PM, Ravi Pinjala <[email protected]> wrote: >> >> >>While I can see the value in some of the suggested changes, you're really >>talking about a completely new protocol here. Something like allowing >>arbitrary data formats, for example, wouldn't work in the current model where >>the hub parses the feed and only sends the differences. >>>>>> >>> >>> >>>One of the strengths of PuSH (relatively speaking) is that it's a fairly >>>simple protocol, and works well in a specific use case. I feel like a lot of >>>the suggested extensions would complicate the protocol disproportionately to >>>the gains that would be made. >>> >>> >>> >>>--Ravi >>> >>> >>>On Wed, May 19, 2010 at 8:48 PM, Monica Keller <[email protected]> >>>wrote: >>> >>>>>>>Guys I just posted a proposal for a new revision to the PubSubHubbub >>>>>>>>spec which includes looking beyond Atom, synchronization and >>>>>>>>authorization. >>>> >>>>>>>>Let me know what you think >>>>http://code.google.com/p/pubsubhubbub/wiki/Pshb_OAuth2 >>>> >>>> >>>> >>>> >>>>>>>>On May 12, 5:04 am, Pádraic Brady <[email protected]> wrote: >>>>>>>> >>>>> Great! Though now I have to update lots of code ;). Good to see it's >>>>>>>>> not dead. >>>>>>>>> >>>>>>>>> Paddy >>>>>>>>> >>>> >>>>> On 12 May 2010, at 07:22, James Holderness <[email protected]> wrote: >>>>>>>>> >>>>>>>>> > FYI, James S just published a new version of the Tombstones draft. >>>>>>>>> >>>>>>>>> >http://www.ietf.org/id/draft-snell-atompub-tombstones-07.txt >>>> >>> >
