OK, I've read RSS 2.0 specification and relevant chapters of "Developing feeds
with RSS and Atom" book.
> But in RSS 2.0, there's no way to update the news
> item without changing the timestamp associated with it.
Well, it seems that in RSS 2.0 there is no way to update the news and mark that
the particular item is updated. The timestamp (the "pubDate") is not really a
timestamp since it could point to any future point, ideologically it denotes a
time when the entry should be "published".
And, btw, why is it a problem, changing of timestamp/pubDate?
The only way to notify reader that there were some changes in the feed (without
full parsing of the feed by feeder and comparing the feed item by item) is to
use lastBuidDate for "channel". While we're at it, currently Hudson does not put
this attribute into the feed at all, and my reader says that the feed's last
modified/updated time is N/A.
And it seems that RSS 2.0 is such a bad format and a very loose standard, so
that every reader have to do the whole feed parsing and uses some trickery to
detect new changes/updates anyways. My reader (Sage) clearly compares both title
and content for every news item. So, if Hudson would just modify titles (when
build is done), that would work just fine for me.
But see below...
> That means the timestamp can no longer represent
> the build timestamp, which is when the build was started.
I probably missing something (please bear with me), but why is it a problem?
The whole procedure to generate RSS feed could be as simple as this:
- Get the latest N builds (currently 10?)
- For every build:
- Get the result.
- If the result is null (build is not done). Get the build
state (SCHEDULED(NOT_STARTED) or IN PROGRESS(BUILDING),
put it in RSS title, and for the pubDate use the timestamp.
- If the result is not null (build is done). Get the build result
(FAILED, PASSED, etc), put it into RSS feed in the entry's title,
as it is currently done, and put TIMESTAMP+DURATION to pubDate.
- Put the most recent pubDate from all the N builds into lastBuildDate
So, for every entry in the RSS feed, its "timestamp" (pubDate) is going to
be either start date (for non-finished builds) or end date (for finished
builds), and the "timestamp" of the entire RSS feed is going to be the most
recent moment when some build either started or finished.
This way we'll get the full picture about current Hudson activites via RSS feed
(whether builds are currently building, and how many are done, and with wath
results).
Some more thoughts – on a model level, we could introduce something like:
getLastStateChangeTime() that would return the time of the recent state change
in the Build, and there could be 3 such moments: SCHEDULED - we return what is
currently called a build's timestamp, IN_PROGRESS - when the build is actually
started to be executing, DONE (when the build is done and results are
available). It would be easier to use this method rather than calculate it in
RSS creation code.
Just in case, here's what the book says about lastBuildDate:
lastBuildDate
The date and time, RFC 822-style, when the feed last changed. Note the
difference between this and channel/pubDate. lastBuildDate must be in the past.
It is this element that feed applications should take as the "last time updated"
value and not channel/pubDate.
<pubDate>Sun, 12 Sep 2004 19:01:55 GMT</pubDate>
RSS cannot be used to publish status of on-going builds, as once something is
posted it cannot be changed.
Removed ongoing builds from RSS. Will be in 1.63.