Customisable RSS feeds

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Greetings One and All

Prey tell, for I have never made one before, what I need to make a  
customisable RSS Feed.  Platform will be WS3 unless there's a *very*  
strong argument for *n*x.

I have a db containing stuff - new stuff arriving on a regular basis.  
Want to give potential clients the opportunity to customise a feed so they  
only receive notice for the type of stuff they're interested in.

[stuff] technical term, the precise definition of which need not concern  
us here - but hey, this is usenet.  Fill yer boots.
William Tasso

Re: Customisable RSS feeds

William Tasso wrote:

Quoted text here. Click to load it

In general you don't.  Make standard RSS feeds that represent the
content the producer is offering (consumer independent). Add plentiful
metadata so that aggregators can filter this as they need. Use nice
stable meaningful URLs to these feeds and keep them supported
long-term. All of these encourage syndication of your feed.

If consumers want customisation and filtering, then have them aggregate
the standard feeds and combine / select what they like.

If your consumers are hitting your site directly (ie without transitive
syndication through an aggregator) and they want filtering, then offer
it to them. But do this by structuring your site internally as a feed
generator and a user-specific filtering aggregator. Keep these two
layers distinct.

For efficiency, then you can provide the two layer architecture here
through RSS/XML fragments at the <item> level and leave them within the
database, i.e. you don't actually need to take the assembled RSS/XML
feed document and re-parse it before aggregating (XML parsing is
server-heavy, much more so than assembly). But keep these two layers
logically separate, and don't ever make selection dependent on
properties that don't make it into the RSS data model. If you're
planning on using it, then add it to the RSS metadata (even if everyone
else downstream is likely to ignore it).

Server-side XSLT is always useful, particularly for transforming
pure-content XML into XML with attached presentation (even just
wrapping up RSS fragments as a branded RSS feed). So long as you cache
your parsed and loaded stylesheets, then it's even fairly efficient.

If you're serious about encouraging filtering or aggregation, then it's
even more important than usual to use RSS 1.0 or Atom and to avoid RSS
2 or RSS 0.9*.

Quoted text here. Click to load it

Platform choice is fairly insignificant, as any credible server
language has all the support you need for DB => XML tools, including
server-side XSLT. Any language that doesn't these days just isn't
credible, QED. So take your personal pick, depending on your hosting
and local skillset.

Re: Customisable RSS feeds

Fleeing from the madness of the jungle
and said:

Quoted text here. Click to load it

I see - thinks I have a shed load to learn here.  Many thanks for your  =

thoughts - of course, they raised more questions than answers.

Quoted text here. Click to load it

ok - tell me if you will, does a feed contain only new data or all?  if =

the latter, how does one manage stuff which is no longer available?

Quoted text here. Click to load it


that sort of thing?

Quoted text here. Click to load it


feeds?  more than one?

Quoted text here. Click to load it

This sounds like what I was asking.  Though I'm afraid I don't (yet)  =

understand the answer.

Quoted text here. Click to load it

ugh - right over my head.

Quoted text here. Click to load it

At last a bit containing buzzwords I can understand :)

Quoted text here. Click to load it

Sounds like a can of maggots in the making.

Quoted text here. Click to load it

Well - I have no idea what tools are available - I'd prefer to  =

build/create/update static feeds offline using tools available within (o=
r  =

callable from) DTS (Sql Server).

FWIW: clients are likely to be interested in a personalised view right u=
p  =

to the point where they purchase.  Then they will lose all interest.   =

Repeat sales through this channel are highly unlikely I'd guess.

-- =

William Tasso

Re: Customisable RSS feeds

William Tasso wrote:

Quoted text here. Click to load it

You always include "the number of items that's useful".  This is highly

It's a combination of several rules, so my code uses a fuzzy logic
component for choosing how many (and even their order, as this can
affect which ones barely make it). It's some mix of "about 15", "How
recent should they be?", "How empty can the feed be?", "Can the feed be
entirely empty?"

Quoted text here. Click to load it

If that's what's relevant to the application, then yes. You can put
_anything_ through this metadata, usually by expressing it with Dublin

Where possible, make use of standard vocabularies. Don't say
"colour:green", say that's it's a colour from the X11 colours or a
Pantone number. You can still use "green", but qualify the property as
much as possible and be more specific. Where possible, have your value
line up accurately with the value you've indicated. "Green" is usually
OK, but "light apple green" starts to care if it's closer to the
vocabulary owner's concepts of "apple green" or "mint green". Don't be
more precise than you're accurate.

Be as understandable as you can, but don't be afraid to be obscure and
unreadable. It's better for metadata to be present and ignored than it
is to not be present. Even if it's hard to use, then it's still worth
making the effort to a few of the audience.  In the example here then
you have two audiences: dedicated readers who can probably cope with
some manual setup, and your own aggregator which can certainly deal
with it.

No-one complains about seeing too-much metadata.

 > > If consumers want customisation and filtering, then have them
Quoted text here. Click to load it

Multiple feeds are good.  Have "Products" but also have "mens clothes",
"womens clothes", "outdoor clothes" and what have you. If you can
identify a potential user community, then roll them a custom URL and a
custom filter. Chances are that it's only an extra line in a SQL WHERE.

Quoted text here. Click to load it

Google for RSS aggregators.

The too-crude ones take one or more feeds and mush them together. The
simplest useful ones do this, but at least know how to strip

Aggregators get _really_ interesting when they can assemble lots of
feeds and select particular items from each one. I've been writing
these for about 7 years now and I still can't get them to work usefully
-- if you want to do item selection, then you need published metadata
to make the choice on. Of course for internal feeds this isn't hard to

Bayesian algorithms and "I liked this, show me more like that" user
interfaces are great.

Quoted text here. Click to load it

You have database stuff and you need to make RSS/XML stuff.

When you go DB -> Filter -> RSS, just do this.
Don't go DB -> RSS ==> DB -> Filter -> RSS
as that RSS ==> DB step is processor-heavy (XML parsing)

Quoted text here. Click to load it

Yes.  If in doubt, use Atom.

The output from your aggregator can usefully be in other formats. It's
an easy XSLT transform to turn a good format (Atom / RSS 1.0) into a
bad format (RSS 2.0) but it's very limiting to go the other way.   So
offer RSS 2.0 as an output option, if you like.  If you're addressing
the podcast market, then you'll want RSS 2.0, as that's all that many
clients will accept.

There's no good reason to choose RSS 1.0 over Atom unless you're an RSS
diehard and you already understand RDF. Processing RSS 1.0 as XML
rather than as RDF/XML removes any advantages you might get over Atom

Quoted text here. Click to load it

I've never done RSS through DTS, but I _guess_ it's possible.

One thing I'm adamant though is that XML should always be generated
through a competent XML DOM. I know you don't have to do this, but you
_will_ see fewer errors about duff encodings if you do this.

Quoted text here. Click to load it

What's the "channel" ?  One customer might want a highly tailored
channel, use it heavily for a few weeks, then once purchased they
vanish forever. However that''s no reason to not offer a good "core"
feed, or to not offer good tailoring through the aggregator.

You might also find that many customers have similar preferences and so
a "templated" aggregation layer is useful. Click the button once to get
"what most 30-something blokes reading Terry Pratchett like to wear",
then use the complicated tailoring selections later, if you can be

Re: Customisable RSS feeds

Hi Andy,

    Thanks for this post. I created a news aggregator at that passes the feed into mysql and then
groups it by user tags so users can see things clumped together that
are related. I like your point about an algorithm to show "more of
this" and "less of this". I am going to use some sort of favorite
system, and then relate other users favorites to build a suggestion

Andy Dingley wrote:
Quoted text here. Click to load it

Re: Customisable RSS feeds

William Tasso wrote:

Quoted text here. Click to load it

FWIW, my article on RSS includes some files that you can download &
customize to create your own RSS feed. In your case, you might use
these files for testing purposes, to experiment with what you want.

Here's the article:

Here's the part with the downloadable files:

TC (MVP MSAccess)

Site Timeline