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

Re: [syndication] shared feed lists

> I don't see any other low-barrier-to-entry way to get those folks in
> the game.  If I did, I'd have never suggested a well-known location
> for the data.

Well given my experience there's not a lot of situations where a site can't
easily integrate this into a page <head> section.

> What a lot of these providers need to learn is that if they begin to
> provide RSSish feeds, many of the brute force scrapers (which use much
> more bandwidth) will likely go away.

Yeah, that's a valid point but does using a bad idea like fixed URLs really
help?

> Well, I spent my first three years at Yahoo working on the Yahoo
> Finance news feeds--doing syndication the hard way.  It was rare to
> work with a provider that could easily and willingly make a change in
> their format, whether XML, HTML, or their own bastardized text markup.
> The reasons were many.  And this was with a contractual agreement in
> place that had a non-trivial amount money attached to it.

Well, not everything sucks that hard.

> It seemed needlessly stupid and frustrating at first, but over time I
> had to accept it as fact.  There are a lot of organizations that
> publish good content but use a real mess of poor tools to do so.  It's
> not a problem we can solve, but it's one can't pretend does not exist.

But as my /experience/ has shown the resistance on the part of sources making
RSS is next to zero on implementing fixes or new features.  They've just not
shown up as any significant quantity of resistance here.

> > > I'm not sure how those offering data dynamically are burdened than
> > > those offering it statically.  Can you clarify that point?
> >
> > How does one take an existing dynamic script and, with no web server
> > reconfig or cron jobs get that kept in sync as a static URL?  As in,
> > they can't get to mod_rewrite and the Options on their hosting
> > provider don't make it possible.
>
> Without a less abstract example, I'm not sure I follow.  Nothing
> against you, I'm just better with concrete examples than
> generalities.  Sorry.

Hmmm, we have personal lists for users.  Mine are listed at:
http://www.syndic8.com/userinfo.php?UserID=wkearney99&Section=lists

How does your fixed URL help me?  What would I list on the root page?  We also
know about 30k+ RSS feeds.  Now, we're certainly an edge case I'll agree.  But
I'm not at all psyched about the idea of a billion nitwits relentlessly
hammering a non-existent URL trolling for feeds every 10 f'ing seconds.  They
WILL do this and it WILL be a train wreck.  But then I'm perhaps being cranky
here.

I have a way to do this and I can easily add <head> section <link> tags that
point to only feeds referenced in that context (none on that page, actually).
But on page like this one:
http://www.syndic8.com/userinfo.php?UserID=wkearney99&Section=list_8
there's quite a few feeds that could be listed.  Now, should they be listed
individually or should I list the URLs for the lists formats themselves (rss,
ocs, opml, etc)?

Likewise, how about sites like LiveJournal (he says while grabbing that box from
Pandora...)?  Or portal sites with per-user features like Drupal or *Nuke?

> It's a tradeoff.  What if the choice was between "don't offer a
> fall-back" and "get these 5 big name news outlets on-line next month"?

So set a good example, put it in the <head> section alone and do NOT use a
default URL.  Let them see the "right way" to do it.  If the content's "all
that" they'll learn from the good example set.  I'm all for making it easy but
not at the cost of burdening sites needlessly.  No big five sites are worth a
damn if it screws 15,000 other sites in the process.

> > A fixed URL tells you nothing about what format it's contents will
> > be.
>
> Sure.
>
> If you fetch http://jeremy.zawodny.com/blah.xml and I've chosen to put
> HTML there instead of XML, so what?

Well, if you're on a Java-enabled cell phone behind what might be a slow and
expensive link you'd sure as hell resent downloading what could be a huge and
worthless file.  Thus using a link with type URL would allow the app to know
ahead of time not to even bother with it.

Much like how CSS and stylesheets work, as has already been pointed out
elsewhere in this thread.

> If I decide to put a different type of XML there (SVG instead of
> OPML), so what?  The tool will figure that out and move on.

Why leave it to chance?  What not allow for extensibility with some brains added
in from the git-go?

> > As in, if someone wants to offer something a lot less dain-bramaged
> > than OPML a fixed URL would leave them screwed.
>
> Assuming that we decided on OPML, yes.

As Sr. Mary used to say "when you assume you make an ass of u and me."  Let's
smother that bad idea right from the start.

> Yes, like the non-option stuff on this list:
> http://www.intertwingly.net/wiki/fdml/

Yep, good ideas.

> > For using /one format for larger purposes/ it might be worth
> > entertaining the idea of something just a /wee bit/ more robust.
>
> Sure.  That's why we discussed having optional elements and extension
> via namespaces.

Namespaces!  Blasphemy!  Oh, sorry, Winer-mode there...  Yes, taking a page from
the RSS-1.0 book on modularity would certainly be a good idea.  Now, if I can
just get you to swallow this little red RDF pill...

> > I've been ruminating on a way to allow different desktop/pda/portal
> > interfaces to share /really robust/ sets of feed data.  As in, sync
> > your work/home/pda/website feeds lists with their read/unread and
> > other stats all within the embrace of an extensible format.  I'm
> > saying that has to happen /before/ site indexes but how about we
> > pick something that'd really leave room for it?
>
> Hmm.

Yeah, my thoughts here are borne from being quite involved and recognizing how
RSS readers can and could be extended to do much more useful things for actual
people.  Not just us geeks bolted to our machines 24x7.  Time and again they
keep asking for things like synchronization and unique item identifiers.  They
/want/ to take RSS beyond the hassles of e-mail but recognize certain things
they /like/ about e-mail.  Anyway, that's wandering way off tangent.  Allow for
extensibility here and it'll allow experimentation.

> > If we're going to set and example and, as a result, have the masses
> > follow blindly along, then why not take a shot at making it a good
> > one?  After all we might only get one shot at it so let's load for
> > bear.
>
> The danger in showing people something more complex is that they
> believe it is complex instead of simple.  That's one thing I worry
> about.

Nah, we can boil it down quite succinctly without scaring them off.  I've even
managed do that quite well with RDF (much to some RDF folks surprise)  As long
as we start the process with the idea of supporting extensibilty and useful
things like namespaces, real container elements and hierarchies then we're going
to be fine.

What's your take on Snell/Appnel's ADX idea?

-Bill Kearney