Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subscribing problem

On Aug 16, 2005, at 3:38 PM, A. Pagaltzis wrote:

I am dismayed to watch so many discussions focus on the common
offering of identical feeds in a variety of formats to the
exclusion of all the other possible scenarios.

Understood, and while I agree that there are many possible scenarios, that doesn't obviate the need to deal with this particular one.

I understand that asking users to pick between identical feeds
which differ only by format is a useless decision. It certainly
is unsatisfactory to require such a choice of them. However,
there currently exists no useful heuristic to identify feeds as
identical with any sort of accuracy.

Agreed. I think what is needed is to figure out what must be done in order to not require the user to make such a choice, especially when many, if not most users will not understand why they're being given a choice at all.

My site offers two feeds for autodiscovery: one is Atom, the
other is RSS. But the two supply entirely different content: one
is my log’s feed, the other is my del.icio.us link log. Why would
software withhold an arbitrary number of choices from the user?

I'm not arguing that it should withhold a choice if two feeds offer differing content. I'd like to try to stick with solving the particular problem that Mark Nottingham raised in the first place. I believe it's mostly a user interface issue, but however much we'd like for there not to be, there *are* political ramifications for having the software choose one format over the other, if the user has no way of setting their own preference. The subtle long-term effect is to promote one format over the other, which is something we can probably agree should be avoided.

There is one somewhat reliable heuristic, which is that when two
different autodiscovery links carry the same non-empty title,
they can be assumed to be identical. Its practical value is low,
though, since this is not currently wide-spread convention among
publishers.

That's one I hadn't thought of. I agree that it's probably of little practical value right now. Perhaps it's worth thinking about a reliable way to decide if two feeds carry identical content. However this doesn't necessarily solve the problem Mark reported, where Safari doesn't know that his news reader only understands RSS and sends it an Atom feed instead.

I don’t see how it is possible for software to make a choice on
behalf of the user without hiding a *lot* of useful information
from him/her.

Agreed.

See also

That pretty much cuts to the core of the issue we're discussing.


On Aug 16, 2005, at 3:44 PM, Robert Sayre wrote:

Well, none of the RSS formats have a mime type, so I'm not sure how
you're supposed to indicate a preference. They often use the
unregistered "application/rss+xml", but that doesn't disambiguate
versions of RSS. They also use "application/rdf+xml" for RSS1, but
that can point at any RDF file (like FOAF).

Ok then. This is a real issue, but I don't think it's necessarily a blocker for solving the problem in Safari. Please don't take this as a loaded question, but is it really necessary to disambiguate between the different versions of RSS aside from RSS1? If so, what's needed? Registering one or more real mime-types? Something else?

support, it wouldn't be nonsensical for Apple to default to the RSS
feed, but this a decision with political ramifications which are
similar to the current behavior of preferring the Atom feed.

I'm not sure why you say the current behavior has politcal
ramifications. I haven't heard much about it. Switching to RSS2
wouldn't have many either, I'd guess.

I'm willing to acknowledge that the political ramifications may exist only in my mind, but my gut feeling is that this isn't the case. As I said above, having the software silently choose one format over another will possibly serve to subtly promote that format, even if only in the minds of some developers. My guess is that switching to RSS2 as the default without giving users a choice, would be seen by at least some in the Atom camp as playing against them.

On a related note, I do think it's a little strange that Apple chose to prefer Atom feeds in Safari, while using (primarily?) RSS 2.0 in iTunes' for podcasting support, but that's neither here nor there when it comes to the issue at hand. The point is that the choice was made unilaterally (though probably not with any bad or political intent) by Apple, rather than leaving the preference in the hands of either content providers or end-users.


On Aug 16, 2005, at 4:35 PM, Sam Ruby wrote:

Here's a prime example: using FireFox, go to http://xml.com/.  Click on
the orange icon in lower right of the window.  You are presented with a
choice between "Subscribe to 'XML.com Articles and Weblogs'" and
"Subscribe to 'XML.com Articles and Weblogs'".  No difference in titles.
 One happens to be in Atom 1.0 format.  The other happens to be in RSS
2.0 format.

Firefox will happily consume both.

Very cool. I didn't know this was the case in FireFox, though I probably should have. Do any of the rest of you see this kind of behavior as a viable solution for Safari?

Users may continue to provide feeds in multiple formats (I certainly do,
including CDF, ScriptingNews, and OPML).  But users should limit
themselves to only providing autodiscovery links to feeds with unique
content.  Perhaps full text vs summary, or with enclosures or without,
but there should be some distinction relevant to end users involved -
and that relevance should be identified in the title.

I have to disagree on this point. The reason that this came up in the first place is that some feed readers only support one format or the other, and users have a real need for the software to be able to find a compatible feed. If a website only provides a link to one format, then all of the users whose software supports only some other format(s) will be out of luck. I think many non-technical users would just say to themselves at that point, "Oh too bad, this site doesn't have a feed. I guess I won't be reading it." Not good, IMHO.

On my site, I provide a feed for my posts, and a feed for my comments.
These clearly have distinct content.  If the client application is in a
position where it can present a list of choices, it should present both,
along with the title string I provided to aid the user in their
decision.  If the client application is not in a postion to present such
a choice, it should select the first (which in my case is the post).

Agreed. My feeling is that this is the right behavior.

IMHO, autodiscovery should focus on this use case.  In many cases, this
means that a user choice will reduce to "subscribe to this feed, yes or
no?".

True in the case where there's only one link, but how often will there be more than one?

In the rare case that you find an consumer who can't handle the format,
then people will have to find the feeds in other ways.  On my site, you
can find the formats I support by clicking on a link marked Feeds.

It's great that you provide a page with links to all of your feeds, and I would recommend that everyone do this, but is it really a rare case that aggregators don't support one or more formats? Shrook seems to be pretty popular, though not as popular as NetNewsWire or Safari itself I would guess. My instinct is that it's worth figuring this out without having to direct users to a page with links to lots of feeds. Also, all that does is push the user's choice out to the website -- a choice has to be made by the user just the same.


On Aug 16, 2005, at 10:27 PM, Phil Ringnalda wrote:

(now politicized) autodiscovery proposals by Mark Pilgrim and  others.

If you can point out where the current RFC is politicized, I'd appreciate it, greatly and honestly. Mark's no longer doing anything with it, I'm "editor" just to run it through the process, but if I missed anything offensive, I'd be happy to take it out before the next draft. (Other than not mentioning RSS, which is just the reality of writing an IETF RFC: you can't normatively reference any of the RSS specs, or recommend the use of an unregistered mime-type, and the mime-type's unregisterable because you can't normative reference any of the specs, and around we go.... Everybody, including Mark, would be happier if we could have a single official autodiscovery spec, rather than a spec and a blog post, but we just can't. At some point, I'll probably register something like feedautodiscovery.org just to have a one-stop place for both exist, but I haven't gotten around to it.)

I don't see anything about the spec that's in itself overtly politicized. The main thing for me is that it doesn't mention RSS of any flavor, nor would the spec as it stands support any future feed formats.

Please understand how this looks from my point of view as a developer and early adopter of the autodiscovery feature. I was one of the first people to add support for autodiscovery to deployed software, within literally days of Mark's initial proposals. At that time RSS was it (though there was still the multiple RSS versions issue and politics around RSS 1.0 vs. 0.9x)...

Anyway, I thought the work was done, the feature appeared to be frozen, and I and UserLand moved on to other work. Much later, and rather innocently I think, Mark Nottingham pointed out the issue in Safari here on this list, and the response from Jessica Kahn, whom I presume is speaking on Apple's behalf, is basically that "this is what the spec says to do".

I found that a bit surprising, if not even a little disconcerting. How would a spec which originated before Atom existed come later to specify that Atom should be preferred over RSS? When I discovered that the spec doesn't say that, and that in fact it doesn't even mention RSS, I became concerned that the changes and/or subsuming of the autodiscovery spec into Atom may have been done for political reasons. I now doubt that this is the case, but please recall all of the controversy over the Wikipedia page on RSS for some idea about why I became concerned about this.

I suppose my real hope would be that the autodiscovery spec could stand on its own, outside of the context of the Atom spec/draft, and that it would explicitly support all of the major syndication formats. I understand that the existing spec, since it's part of the Atom spec/draft really probably shouldn't refer to RSS, but would it really be a problem for Atom to refer outward to a separate document, which also documented its use with RSS, and also left room for any future formats?

Also, please don't take this as a loaded question, but how was the decision made to incorporate autodiscovery into the Atom draft in the first place? Or is that not what happened?

Thanks,
-Jake
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
syndication-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/syndication-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Subscribing problem (From: Robert Sayre <email@hidden>)
 >Re: Subscribing problem (From: Jake Savin <email@hidden>)
 >Re: Subscribing problem (From: Robert Sayre <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.