[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] shared feed lists



On 10/14/2003 10:02 AM Bill Kearney noted that:

> What's unrelated about it? They're probably already pulling the web page. Why
not give them a <link> tag that has a specific type attribute telling them "This
is the Feed list URL"?

I hear you, but the overhead kills on wireless devices and similar.



It seems far more likely that yours is the edge case.  Feeds without a web page?
I could see why someone might create such a thing but in my experience (with
Syndic8) it's not happening in any great quantity.

Possibly - I'm not quite sure that it will stay that way going forward. For instance, my NOC guys feed all of their system events and notices into an RSS feed that has no attendant HTML (easier to parse into whatever the important app-o-the-moment is) - my email aggregator works the same way - I've created RSS feeds for each mailbox and newsgroup that I read. OCS binds it all together. Look ma, no HTML ;)


Here's the thing, you can put a <link> tag in the HTML pages and if anything,
looking at any of your HTML pages looks at it they'll be able to make a
successful request right to the correct document.  No error log entries.  That
and assistive tools like browser bookmarkets can quite easily pick up on it and
use it while already having downloaded the HTML page.  Extending them to do
'favicon.ico' hacks is actually a fair bit more difficult.

Then there's the situation of a hosting provider that has many users, should the
root of the site be /required/ to use this index?  Forcing them to use a fixed
filename would needlessly require them to write the static file.  Either that or
cobble up rewriting solutions.  Again, to what valued end?  This as opposed to
suggesting an agreed upon <link> tag type and their option of what sort of URL
to use.  No restrictions against using dynamic scripts and no harder-than-needed
server alias or rewriting rules.


Sounds like the right approach is:

<mumble, mumble> MAY use predictable location voodoo.
<mumble, mumble> MAY use <head><link> voodoo.
<mumble, mumble> MUST use one or the other or both voodoo.

Entirely inelegant but completely practical. Not sure if we really need to return a binary answer for this query.

I agree OCS has already been doing this for well over two years.

Glad to see I didn't miss anything - I'd hate like hell to have to go back and change everything we did in this regard ;)

In all seriousness, whatever the answer to the discovery question ends up to be, we'll likely support it. In the meantime, *our* right answer has been to go the predictable location route. ie - http://www.byte.org/ocs.xml - I can't see us going with exclusively with OPML, but it might be something that we would add if there's any demand.


--


                       -rwr








                "Don't be too timid and squeamish about your actions.
                                           All life is an experiment.
                            The more experiments you make the better."
						- Ralph Waldo Emerson

Got Blog? http://www.blogware.com
My Blogware: http://www.byte.org