Forum OpenACS Q&A: Would you like to publish your ACS objects with RSS?

I have created an OpenACS 3.2.5 tcl library file to generate RSS 0.91 and RSS 1.00 feeds. The file is just Tcl, though it relies on OpenACS 3.2.5 versions of ad_proc.

Basically, for each item (news event, ticket, bboard message, ...) that you want to publish, you create a property list that describes that item (url to item, title of item, description of item, etc.). You pass a list of those items (and some other parameters) to rss_gen, and it will generate your XML for you.

As a demonstration, I have created a crawler that visits the OpenACS bboards every twenty minutes and creates an RSS summary of the most recent 15 messages. You can see the XML here, or see how one web service would render that here requestname=RSSGet&uri= forums.1.00.xml

Within a day or two, you should be able to pick up those feeds from Syndic8 or from

This would be *very* easy to wrap into an OpenACS 4 package since there's no datamodel.  It would make a *great* example of a service contract-based package that could be easily called by a variety of packages.

If you don't have time to do it, maybe someone else would?  Any takers?

As we discussed in email, (I hate dangling threads much worse than dangling modifiers), yes, right now I do have limited time (in part because I want to get busy scraping aD)).  I would be happy to help anyone that wishes to move this to OpenACS 4.  I definitely want to see RSS capabilities in OpenACS 4.
If you click on requestname=RSSGet&uri= and it appears to give you back garbage, hit refresh. There is some bug being expressed at soapclient: it caches the RSS feed returned from a source, but it appears to barf on the presentation of the feed when the cache is empty, or very old (and refreshed.)
This appears to work with little modification on OpenACS4. Here's what I did:
  1. Create a singleton service package
  2. Change tcl library file names to blah-procs.tcl so that APM will actually load them.
I'll take a look at the service contract stuff over the weekend. Who wants to host this package?
Hey that's great Andrew!  Perhaps you can put it in /new-file-storage here, or I'd be happy to host it at the end of my DSL line until the new openacs site and the new repository are implemented.

I am not sure if this should be in the same package or a seperate one, but I was planning on adding in the ability to parse RSS feeds from other sources.

If we can get this tested and documented and provides a service contract, I have no problem with our putting it into our tree, with Jerry, Andrew and Dave (or some subset or superset agreeable to themselves) having commit privs to it.  "documented" is a bit of a problem at the moment since AFAIK we don't have our XML act together yet, but someone could start writing words with the notion of marking it up later.

What about Dave's question?  Should we include parsing of feeds in the same package?  Hooking this up to OpenACS 4's a bit more difficult because, much like acs-mail, we probably want to stuff content into the db.

Perhaps we should be satisfied with rolling out the existing Jerry+Andrew work for now ...

I've sent a separate email off to Jerry asking him to edit the package info file.  After that we'll post a version to new-file-storage and link from here.

Dave, these may or may not belong together, haven't thought about it.
Perhaps you can take a look at Jerry's tarball and make a recommendation?

Whoops, Don and I made our posts at the same time.  Don, CVS is fine w/me.
Come up with a name for the package that you folks are willing to live with for a long time and I'll open up a slice of the CVS tree for you...

Just e-mail me when y'all decide!

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,, moreover, xmltree, newsisfree (most of whom are using ocs (, and now *any old* openacs site can have user configurable portals that can take feeds from thousands of news feeds from around the world.! 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!)


Short, short answer:

Other packages should communicate with the RSS package via asc-service-contract contracts. I think whether or not, or how to store accumulated RSS data should reside in yet-another, or each individual package. With this method the underlying code can change as long as the external representation via the service contracts stays the same.

Individual packages could also communicate "new-stuff" to each other or a generalized system via acs-service-contract. I haven't looked into it too much, but it appears to be an answer to many questions we are running into.

Can someone confirm my thinking here? As long as we are looking at extending packages and adding new ones, I think this issue needs to be addressed. I do NOT want to distract from the immediate goal of a working OpenACS 4 release though. I just want to save people some trouble who may be working on packages and services they need to get a site up and running.

All I know about acs-service-contract I just learned from google and

And I certainly don't want to delay openacs 4.

Differences I see between using acs-service-contract and using some piece of XML are:

  • the XML contracts are probably slower. how much?
  • the XML contracts can be fulfilled between any xml aware application. That might be
    • two acs modules that might more efficiently use acs-service-contract, or
    • it might be between any xml/soap/xml-rpc applications on the net, or
    • the user aided by a point and clicky configuration widget
Search engines and ecommerce gateways are probably ideal examples of why and when to use acs-service-contract. Portal configuration by the user in a browser widget is the canonical example of when to use RSS or some XML to communicate. Perhaps site map querying is a good example for using both interfaces?
I've been wanting to put off this conversation until we get s solid first-generation release out, but ...
Yes, Dave, the informal plan is to use acs-service-contract in the way you describe.
I'm not terribly interested in trying to support *two* interpackage integration strategies.  Neophytos and Kapil have been doing some thinking about integrating SOAP/XML-RPC services into OpenACS 4 so it's not as though this issue is being ignored.
At the moment I'm concerned that it would be very easy to get distracted by chasing what are admittedly a bunch of cool possibilities for future work.  Unfortunately, ACS 4.x as inherited somewhat resembles what's left behind after the sewer backs up, and I dearly want to see the mess cleaned up as much as possible, as soon as possible, so we can have a reliable technology base to build upon.
If I'm coming across as a bit of a grinch here, you can be certain it's not because I'm not interested in implementing a much better framework for interoperability between packages within OpenACS, and OpenACS sites with remote servers.  I just want to get a solid release  shoved out the door!<p>

Neophytos and I have discussed restructuring around acs service contract.  My response has been of the "yes, of course, we should do that but , umm ... does OpenFTS work yet?  We need that first!" (you can substitue a long list of strings for "OpenFTS" without changing my point!)  We left off in agreement that we should start a public discussion about how we might want to use acs service contract as a restructuring tool at the point where we have a solid beta release of OpenACS 4 bundled and out the door.<p>

Note I said "beta", not "final" - I'm not being entirely anal, I hope!<p>

Entirely by coincidence Neophytos has
<a href="/bboard/q-and-a-fetch-msg.tcl?msg_id=0003B8&topic_id=12&topic=OpenACS%204%2e0%20Design"> posted</a> a reference to a
paper discussing contracts which he thinks is really cool.  I plan to read it, maybe you folks would like to, too?
Comments should probably go into the thread he started rather than here, since it's entirely about OpenACS 4 design ...

There is now a working version of the contract-based rss report generation code in CVS.  The package is called "rss-support".  The package comes with design notes and sample code which demonstrates an implementation for bboard forums.

It would be valuable to try this stuff out For Real.  Are you
running an OpenACS 4x site?  Would you like to test out this new
package?  If so, grab the code and let me know.