My vote would be to include parsing of other RSS feeds. It's my suspicion that RSS generation and parsing is a necessary but not a sufficient end point for OpenACS RSS support.
I don't know very much about OpenACS 4 capabilities, but I like some of what I had been hearing on #openacs, which is to utilize these capabilities in some other openacs substrate: portals, or somewhere else, to make the abilities native and standard to many openacs modules.
As an example, prior ACS versions have a pretty neat "what's new" system, but few modules implement it. I imagine what we all would like to see is that anything that inherits from *something* gets RSS generation capabilities which can then be modified as needed. Now I don't know what that *something* is, and so I don't know if what I seek is feasible.
The point is, that since the question of how to truly integrate this into OpenACS 4 is still up in the air, and since RSS generation and parsing is just not enough anyway, I definitely think that this lowest of low level RSS support should include parsing and generation. That will give any developer some working, standardized, toys to play with, and that should help us define how we might really want to support RSS in OpenACS 4. (Let's include a disclaimer that this is one API that is expected to change.)
If you include both RSS parsing and generation, then to a limited extent you have the ability for one ACS module to communicate with another module using standard ACS tools, and encapsulating the SQL into the targeted module. In OpenACS 3.2.5 terms, that would be an enormous win. I don't want to make this seem like the ultimate panacea (as RSS is not rich enough (but an RSS 1.0 extension might be)) nor the ultimate win, but it would be applicable in many locations throughout the ACS. Yesterday there was a discussion of how to determine the URL of another package instance. Perhaps there should be just a procedural API to do that. But maybe the site-map could publish an RSS list of package names, their URLs and a description. That could open up the browsing of the site-map and configuration of a package to the user.
RSS parsing would enable a user configurable portlet like module (excuse the imprecision, I have never used portlets) that can subscribe to any RSS feed, whether that feed is from the local OpenACS instantiation or elsewhere on the net. Bundle that in with an OpenACS browser of the feeds from my.userland.com, syndic8.com, moreover, xmltree, newsisfree (most of whom are using ocs (http://internetalchemy.org/ocs/index.html)), and now *any old* openacs site can have user configurable portals that can take feeds from thousands of news feeds from around the world. Your.yahoo! in a can. If you're building an intranet or extranet site, and RSS generation is somewhere in the content repository, then this portlet would make it very easy for employees, departments, teams, partners, to communicate with each other on their own portal pages (while still including the latest britney spears news!)
