Re: Digest Number 1076

Yeah, the point isn't to break anything.  There are some situations where
it'd be handy to be able to do some smarter handling of feeds.  One thing
that might help the process is being able to show something a little more
descriptive about the 'currently available' feed.  Granted, this is
fundamentall what a lightweight feed itself is *supposed* to be doing
already.  But given the existance of full-content feeds or dynamically
driven feeds it might be worth discussing some evolutionary ideas.

For example, a feed of video clips might have a boatload of things "today"
that don't interest a reader.  Thus letting their aggregator be able to
avoid downloading the subsequent enclosure elements would be a nice option.
Sure, it'd require the user to "look" at the descriptive data and interact
with their reader and this function is outside the scope of how current
readers handle things.

This also touches on the idea of per-item accessibility as 'raw data' in
addition to their existance as HTML web pages.  Being able to download a
lightweight RSS feed that contained links to actual per-item "full content"
would perhaps also benefit from 'active descriptions'.  A lot of what atom
is attempting to provide may cover some of this but there's no harm in
considering the idea in the context of RSS as well.

Part of what raises this question is one of balancing resource consumption.
Having full-content feeds is a huge waste of resources.  Granted, some folks
don't "care" about the waste and I'm not saying they should be prevented
from continuing it.  But a great many folks run afoul of serious bandwidth
limitations they can cause.  Thus being able to keep the feed lightweight
while also providing complete XML data per-item might be a nice alternative.
This would, of course, require the reader programs to do a bit more work.
Those that want to pull full content would be able to continue to do so by
having their reader opt toward pulling the items in addition to the feed
itself.  Some are already doing something like this when they handle podcast
enclosures so it's not too much of a stretch to consider full-content items
in a similar fashion.

Anyway, the point here is to get a discussion going on the relative merits.

-Bill Kearney
Syndic8.com

----- Original Message ----- 
From: "Stephen Downes" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 24, 2005 11:49
Subject: Re: [RSS-DEV] Digest Number 1076


>
> Hiya,
>
> I'd rather see a new channel element created than to see the current
> description element broken.
>
> -- Stephen
>
> [email protected] wrote:
>
> >   Date: Thu, 24 Mar 2005 10:20:18 -0500
> >   From: "Bill Kearney" <[email protected]>
> >
> >Granted, given the current semantics of how RSS is polled there isn't a
way
> >to "do this".  But everything evolves over time and I'm wondering if
anyone
> >else sees merit to such a thing?  I realize this would 'break' the
semantics
> >of how a feed is retrieved and current tools wouldn't grasp using it
without
> >new code being written.
> >
> >
> >
>
>
>
> -- 
> ---------------------.sig--------------------------
> Stephen Downes  ~  National Research Council Canada
> http://www.downes.ca  ~  [email protected]
> ---------------------------------------------------
> The best daily online learning news and opinion:
> OLDaily  ~  http://www.downes.ca/news/OLDaily.htm
> --------------------------------------------------- 
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>



 
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/