I'm sorry I expressed that terribly. I think some hubs will change some metadata or their functionality will be very restricted. But that's ok - the message content and identifying source is what matters?
On Tue, Oct 20, 2009 at 12:15 AM, Jay Rossiter <[email protected]> wrote: > > "it" would be the hub. When the hub sends updates to its subscribers, > the data that it sends should be identical to what it received in the feed, > with the exceptions of what is required to handle the protocol. Unknown or > invalid tags... everything contained within the item/feed being handled. > > In short, the hub should never change anything that it is not > specifically responsible for maintaining. > > > On 10/19/2009 4:07 PM, Alexis Richardson wrote: > > By "it" do you mean the message payload, or something more? > > > On Tue, Oct 20, 2009 at 12:05 AM, Jay Rossiter <[email protected]>wrote: > >> >> It's my stance that it should pass through everything completely >> untouched, except as *required* by the hub spec. (i.e. addition of >> atom:source when aggregating.) >> >> Anything short of that, in my mind, is mishandling of the content, and >> I certainly wouldn't use any hub that made modifications to my distribution. >> (Whitespace/etc. aside) >> >> On 10/19/2009 3:41 PM, John Panzer wrote: >> >> An important practical question that is going to come up is whether a hub >> should pass through things it doesn't understand, in particular, extension >> elements that it doesn't know anything about. This should be explicitly >> mentioned in the spec IMHO, because many libraries simply drop things on the >> floor that they don't grok. Or, they just drop pieces on the floor. >> I vote for pass-through of unknown elements (and attributes, but at >> least all attributes on unknown elements) being at least a SHOULD. >> -- >> John Panzer / Google >> [email protected] / abstractioneer.org <http://www.abstractioneer.org/>/ >> @jpanzer >> >> >> >> On Mon, Oct 19, 2009 at 3:15 PM, Bob Wyman <[email protected]> wrote: >> >>> On Mon, Oct 19, 2009 at 6:06 PM, Tim Bray <[email protected]> wrote: >>> > "The intent of this specification is that hub >>> > implementations SHOULD distribute faithful >>> > copies of the feeds as provided by the publishers. >>> >>> I'm somewhat concerned that people might read these words and assume >>> that "feeds" is synonymous with "feed documents." Such a reading could make >>> all sorts of trouble with attempts to reduce propagation of duplicate data, >>> exploitation of opportunities to aggregate, etc. It's not the "feed >>> documents" that need to be distributed faithfully but rather the content of >>> the feed documents -- the Atom Entries or Entry Documents... >>> >>> bob wyman >>> >>> On Mon, Oct 19, 2009 at 6:06 PM, Tim Bray <[email protected]> wrote: >>> >>>> >>>> On Mon, Oct 19, 2009 at 6:45 AM, Brett Slatkin <[email protected]> >>>> wrote: >>>> >>>> >> I think there needs to be quite a bit more clarity here. It's clear >>>> >> that the hub is required to preserve the atom:id. How about the >>>> other >>>> >> elements? I would be *very* nervous about a hub that screwed around >>>> >> with my atom:updated or other header fields. The current text sounds >>>> ... >>>> > My response to this would be, if you don't like how a Hub screws with >>>> > your content, then don't use that hub to distribute your data. >>>> ... >>>> > Does that make sense? Is there anything that would clarify this in the >>>> > spec? >>>> >>>> Yeah, it's clear that no spec can enforce ethical behaviour on the >>>> part of of hubs. I am left troubled though by the >>>> hint-between-the-lines flavour of the 0.2 daft, and I do think it's >>>> important to set expectations. Let me propose some text that might >>>> help move this discussion along: >>>> >>>> "The intent of this specification is that hub implementations SHOULD >>>> distribute faithful copies of the feeds as provided by the publishers. >>>> In some cases hubs may offer to enhance feeds, for example with >>>> statistics or translation. However, this specification cannot >>>> guarantee the faithfulness or integrity of hub implementations. >>>> >>>> In particular, the <atom:id> elements of feeds and their entries, >>>> preservation of the exact value provided by the publisher is crucial >>>> to the integrity of the whole feed ecosystem. Thus, implementations >>>> conforming to this specification MUST reproduce the atom:id value >>>> exactly as provided. Also, the other elements required by the Atom >>>> specification, when provided by the publisher, MUST be present in the >>>> version served by the hub." >>>> >>>> I.e., in English, "We can't guarantee that hubs won't be evil or that >>>> they'll provide bit-for-bit copies. But they really shouldn't mess >>>> with atom:id and they shouldn't leave out required elements if you >>>> provide them." >>>> >>>> Based on bitter experience with implementors who have fairy-story >>>> beliefs that specs can enforce integrity, I think that some explicit >>>> warning is called for here. -Tim >>>> >>> >>> >> >> >> -- >> >> Jay Rossiter | Software Engineer/System Administrator >> Pioneering RSS Advertising Solutions >> >> [email protected] | Phone: 503.896.6187 | Fax: 503.235.2216 >> Website: www.pheedo.com | RSS: www.pheedo.info/index.xml >> > > > > -- > > Jay Rossiter | Software Engineer/System Administrator > Pioneering RSS Advertising Solutions > > [email protected] | Phone: 503.896.6187 | Fax: 503.235.2216 > Website: www.pheedo.com | RSS: www.pheedo.info/index.xml >
<<pheedo.gif>>
<<image/gif>>
