Re: RSS Revision - IssueMinimumOneItem

> Most readers I've used will show read items by default; the exceptions
> I've used are RSS Bandit, if you're looking at the "unread items" view
> (which is very useful), and Firefox's RSS support, which is
> ... idiomatic.

Yes, you're right.  They 'show' the item, they just don't show it
highlighted in the same way as an item that's already been read.

I do see your point about wanting a feed where 'no news is good news'.
Having no items as a way of saying there was nothing to be said.  This
raises a different issue, however, concerning how to state the range of time
your feed is covering.  The lightweight nature of RSS for news-like feeds is
one of it's greatest strengths.  When more complex situations develop some
of it can be handled with modules.  But the basic semantics of it being a
short summary of news-like headlines does present some limits on how wide a
set of solutions it can offer.

> What if the most common client program is a simple RSS aggregator, and
> the most common user doesn't want to be notified of resolved issues,
> only unresolved? You seem to be saying: you can't do this. (This is
> why I'm saying "maybe I shouldn't be using RSS here".)

Or consider that different output streams (feeds) could be considered.  If
you're generating the feeds dynamically you do have the ability to see what
client software (user-agent) is being used to pull the feed.  Perhaps your
output could adjust itself accordingly.  For situations where you know the
client tool can or can't handle it then send it different output.  There's
also regular HTTP authentication (user/password) mechanisms to consider.

> > Since RSS is polling oriented it's entirely reasonable to use the
> > HTTP transport mechanisms for indicating unchanged status.  Thus
> > there's no need to send ANY data at all since nothing has changed.
> > Thus it's a non-argument about having zero-elements.  (I'll grant
> > you this is a shortcut argument...)
>
> Erm ... I'm not certain I understand. You're saying if we have a
> warning ("Foo is on fire"), then it's resolved ("Foo has been put
> out"), you get the following behaviour:

Which got mangled due to mail/font inconsistencies.

> C doesn't get a terribly good experience out of that (unless the
> historical situation of Foo is important, such as its being their
> lunch).

I'm sure arguments can be made both ways.

> Well, yes. (But: eww.) Most people won't be using the custom client,
> though.

There is more than one way to skin this cat.  See my previous comment about
regarding detecting user-agent.

> I can build something that isn't a hammer, but if they already have
> hammers, they might treat my screw like a nail anyway :-)

Oh most certainly true.  And bitch about how shitty your screws are at being
nails.

> This is how Firefox does things, I think (Live Bookmarks). Of course,
> it still has HTTP caching.

I've not taken a look at the latest firefox so I've no idea.

> My empty feed would have ETag happiness, providing the HTTP client
> cache was good (I have no idea if Mozilla or MSIE do the right thing
> here). I'd be happy if someone hit my site (custom application, for
> only a few thousand people in the world) for a feed that told them
> tasks they had to do. If they have none, the feed will match an
> earlier ETag, and a good implementation will just get 304; otherwise,
> they get content telling them what to do.
>
> Again: perhaps this isn't RSS 1.0 territory. If it isn't, I have to
> use another RSS breed,

They're all going to be the same in this aspect.

> or roll my own client for everyone to use (and
> believe me, just because I only have a few thousand users doesn't mean
> I can roll out a custom client easily :-).

If it provides compelling enough functionality then they'll want to put
forth the effort.  Consider, however, that maybe it might be better to have
more than one feed and/or do server-side processing that adjusts the output
accordingly.

> I can't see another RSS
> breed being easier to work with, but perhaps I'm wrong ...

Well, it's a fine line.  Sometimes it's tough to reconcile between what the
spec allows, how existing tools use (or misuse) it and what the users
perceive is going on.

-Bill Kearney



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/