When David Czarnecki recently announced the FreeMarker dispatcher for blojsom, I mentioned to him that I have been thinking about creating an iCite dispatcher as well. The idea is simply that an iCite (er, should one ever go live) could be a source for a blojsom blog.
One thing about this that I thought might be cool is that iCites can aggregate content from remote sources. So, I realized, if such a dispatcher existed, it would effectively act as an aggregator. And, so, I thought a similar RSS / Atom aggregator dispatcher would be neat.
My basic idea for the RSS / Atom aggregator dispatcher for blojsom is that it would need to have its own configuration file that would hold a list of RSS / Atom sources to include. With this list, I think it might be interesting to have configurable URL mappings for the aggregation, so, for example, you could mix and match multiple feeds into a single blojsom "blog category".
For example, I could have a /tech mapping, creating a blojsom "tech" category, and that could aggregate various tech sites and blogs. I could have a /friends mapping for friends—and, I might personally organize sources into facets where the same source might appear in more than one category.
The configuration file might include something like:
source=http://icite.net/blog/?flavor=rdf;/tech
source=http://www.blojsom.com/blog/?flavor=rdf;/tech
source=http://www.blojsom.com/blog/?flavor=rdf;/friends
Another configuration might be whether to include local files as blojsom already does. This could be done (I think) by having the aggregator dispatcher call one of the other blojsom dispatchers (e.g., Velocity, JSP, FreeMarker) to get the local files.
Mappings / categories would need to account for the mix of aggregated sources and local files. One nice feature of this might be that a person could use blojsom for a public blog, but as a private aggregator (i.e., the aggregated sources could be located outside of the public blog navigation).
With an iCite dispatcher, basically what it would provide is the means for dynamic categorization of sources, remote retrieval and caching (and, to some degree, parsing) of the sources. So, the RSS / Atom dispatcher would need to handle the retrieval, caching, and parsing.
It could handle the categorization of sources in the configuration file as described above, which would not be particularly dynamic, but would be sufficient for many common aggregation uses.
Because blojsom is so flexible with its flavors, it would be easy then to take the aggregated sources and display just the headlines, or use the show-me-more or limiter plugins, etc. The Xpath plugin would be interesting in this context as well ;-)
I guess another way to look at this is that the dispatcher would retrieve a bunch of XML files on some periodic basis, and a dispatcher would simply be able to parse those files.
So, does this seem workable, or did I miss some major thing? I think it would be fun!
P.S. I am a little on the verge of getting this flu going around, so sorry if this is in any way nonsensical!
Note: All comments and trackbacks are moderated. Spam is deleted. Other comments are approved as promptly as possible.
Note: Older posts no longer accept new comments or trackbacks.
Comment by: David Czarnecki · http://www.blojsom.com/blog/
posted: Dec 5, 2003 8:33:09 PM
Jay, good idea. I'd approach it as follows. 1) Use category meta-data to store the list of URLs or feeds. 2) Develop a plugin that periodically retrieves entries from the feeds in various categories (if applicable) and write the entries to that category.
Essentially, blojsom becomes an aggregator and viewing your blog is basically equivalent to reading everyone else's blog who you aggregate and everyone else basically sees your aggregation if you make that blog available. So, you could have a local instance of blojsom that you use as an aggregator. So, why not a dispatcher? A dispatcher should really only be concerned with taking the entries and the context map and making available those objects in the correct way for that presentation technology. It's only concern should be how it renders the information its gotten. Hope this helps clarify things. It's how I would do it and that's not necessarily the right way.