Forum OpenACS Development: RSS Design Problem

Collapse
Posted by Malte Sussdorff on
Currently the Lars Blogger RSS Subscriptions provide a problem in the way that for each subscription a new directory is added to the /home/pi/openacs/rss/pinds_blog_entries directory. This file is needed so users can access the site and get their rss subscription. With 32*** subscriptions you suddenly hit the linux limit for the number of directories in one level.

This design was chosen so we would not run into problems with a multitude of RSS Readers hitting the database to get the XML Feed. In my opinion though this is *highly* unlikely to happen.

Therefore I'd say it is a design flaw to store the file in the file system as you could just as well store it in the database and use cr_write_content or similar to deliver the "file" back. As the impl_name is provided as well as the summary_context_id we can figure out the impl_id from the impl_name (acs_sc_impls) and store the XML as a new field in rss_gen_subscrs.

This would mean rewriting the rss-support package so that rss_gen_report will store the XML in the database and rss_gen_report_file will deliver the XML instead of the filename. Which means rewriting all packages that use rss_gen_report_file.

The alternative solution would be to adopt the system used in content-repository to store the files, so you have a multitude of directories and subdirectories aso.

Please advise, as we are going to have to fix this for a client of ours and either way probably is an equal amount of work, but I'd prefer the database solution.

Collapse
2: Re: RSS Design Problem (response to 1)
Posted by Dave Bauer on
Malte,

Obviosuly you are not building a popular public web site, but must be using RSS for some other type of system.

"caching" the rss in the database seems like a reasonable compromise, but it probably should be optional. It only requires one hit to the database to deliver the file instead of actually rebuilding the content.

Probably the "ultimate" solution is to use the syndication table to cache the xml fragments, and rebuild the RSS from there. I am using that for all the RSS support I am builiding for clients these days. It allows for custom RSS feeds bsaed on various criteria including search.

Collapse
3: Re: RSS Design Problem (response to 2)
Posted by Malte Sussdorff on
Okay, maybe I'm not clear. The current design of OpenACS stores the RSS in the file system with each impl_id / summary_context_id using one directory which contains exactly one rss.xml. This is the reason why the popular public web site brings me so much trouble.

So, instead of "caching" the rss.xml in the filesystem I wanted to cache it in the rss_gen_subscrs table, as this is the table which is used for generating the rss feed anyway.

Not sure though what you are talking about with the rebuilding the RSS from the XML fragments. Maybe you could elaborate a little bit more?

To be honest, I have not much clue about RSS at this point in time. I just need a solution for the simple problem that I ran out of directories on a public server of a client using Lars Blogger.