Forum OpenACS Q&A: Would you like to publish your ACS objects with RSS?
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 http://www.theashergroup.com/demos/rss/openacs-forums.1.00.xml, or see how one web service would render that here http://soapclient.com/RSS/RSS.sri? requestname=RSSGet&uri=http://www.theashergroup.com/demos/rss/openacs- forums.1.00.xml
Within a day or two, you should be able to pick up those feeds from Syndic8 or from my.userland.com.
If you don't have time to do it, maybe someone else would? Any takers?
- Create a singleton service package
- Change tcl library file names to blah-procs.tcl so that APM will actually load them.
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.
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 ...
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?
Just e-mail me when y'all decide!
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!)
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.
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
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 ...
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.