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

Re: [syndication] shared feed lists

On Tue, Oct 14, 2003 at 04:11:00PM -0400, Bill Kearney wrote:
>
> 
> > 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 believe it's safe to say that you and I have had different
experiences when it comes to the willingness and ability of
organizations to make those sorts of changes.

> > > > 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

I see.

> How does your fixed URL help me?

I'm not sure it does.

> What would I list on the root page?

I don't know.  This seems like an unintended use of the data we're
talking about, so I'm not sure how it fits in.

> We also know about 30k+ RSS feeds.  Now, we're certainly an edge
> case I'll agree.

And there's Technorati with 1,000,000 blogs, many of which have
feeds... :-) But I don't expect Dave to drop reference a "feeds.xml"
file *anywhere* on his servers--root level or otherwise.

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

Not cranky, but overly dramatic perhaps?

They'd use even more bandwidth if they *found* a file there, no?

> 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).

Yes, that's what I'd recommend.

> Likewise, how about sites like LiveJournal (he says while grabbing
> that box from Pandora...)?

What about them?  I don't understand what they'd use this markup for.
Isn't that sort of like going to the library and asking for a list of
all the fiction books they have?  Who'd do that?

> Or portal sites with per-user features like Drupal or *Nuke?

Now that's a case I hadn't thought of...  I could foresee them offering
a list of "user feeds" as well as "category feeds" for their various
news categories.

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

I think the problem here is that you and I (and possibly others?) have
different ideas about the degree to which this burdens sites.

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

Just because I say something is type "foo" in a link attribute doesn't
guarantee anything.  That's the point I was making.  The only thing you
can absolutely trust is the file itself.  Try renaming "foo.jpg" to
"foo.doc" on Windows sometime for an example of how relying on that
sort of metadata can go wrong.

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

That was suggested by those with more XML-fu that I have.  I trust
their ability to think about future-proofing XML because I know little
about it.  I write code to consume XML once in a while but rarely to I
worry about producing it.

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

Good.  We have a similar goal in mind.

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

I see.  Thanks for clarifying that.

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

Care to stick a boiled down suggestion on the Wiki or the list here?
If I get a chance I may to one too.  It might be helpful to look at
implementations as well as requirements now.  So far, Dave Winder is
the only one to produce an implementation (if you brush aside the
pre-existing stuff that may also solve this problem).  Well, he had a
bit of a head start too.

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

I need to look at that tomorrow to see what it's about...

Jeremy
-- 
Jeremy D. Zawodny     |  Perl, Web, MySQL, Linux Magazine, Yahoo!
<Jeremy@Zawodny.com>  |  http://jeremy.zawodny.com/