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 >
<<pheedo.gif>>
