--- In radio-dev@yahoogroups.com, "Marc Barrot" <info@p...> wrote:
> There is no bug in xml.rss.compileService after all, just a bug in my
> understanding of the whole process :-)

Well, my first impression was correct after all, I think there *is* an
error in the logic of xml.rss.compileService.

It would be nice if a member of the Userland dev crew, ideally Jake
since he has contributed part of the code, could read my description
below and at least acknowledge the problem, or correct me if I'm
missing something.

There are 2 main logical steps in supporting item sub-elements of a
namespace defined RSS 2.0 module in Radio's aggregator.

The first one is to make sure that module defined XML elements
inserted under each ITEM element of the RSS feed are properly stored
in the 'compilation' subtable of the subscribed 'service' for that RSS
feed.

This step is handled by the module driver.

The second step is to make a copy of the *compiled* module specific
elements in the proper entry of the aggregatorData.stories table,
which is the base upon which the News page of Radio's desktop web site
is built.

Optionally, one may modify the storytext string in the stories' table
entry, to display an HTML rendering of the module specific elements
with the aggregated story.

The second step must be implemented inside a storyArrived callback script.

So here is the flaw in the aggregator's algorythm:

For all item level elements found in the source RSS 2.0 file, the
xml.rss.compileService script calls the storyArrived callback scripts
*before* calling the module drivers.

As a result, when the callback script executes, the *compiled* module
defined elements are not yet available for inclusion in the
aggregatorData.stories !

The solution is to move the call to runModules in
xml.rss.compileService 2 lines up so that it is performed before the
call to addHistory, which triggers the storyArrived callback stack.

...
for i = sizeof (itemlist) downto 1 //each item is the address of an item
...
bundle //9/30/99 by DW, get the categories, if there are any
runModules (item, adrRss, "", adritem) //run modules for
sub-elements of <item>
addToHistory (adritem, catlist)
bundle //get source, it's optional in 0.92 and greater
...

I've tested this solution on 2 of my Radio installations with the
enhancedAggregator tool, and it appears to be working fine.

Cheers

Marc