pkeane wrote:
Following on my "Why Use Atom?" posting.... I am trying to figure out if
I would simply be pushing Atom beyond its practical limits to build an
entire web application as Atom publishers and consumers. I'd like
implement an MVC architecture where the layers all spoke Atom to one
another. All database access would be mediated by an Atom feed (read)
and AtomPub interface (write). Everything from error logs, image
slideshows, collection settings, incremental backups, etc. would be
mediated by way of an Atom feed. Search would simply be an OpenSearch
implementation that the application itself exposed and consumed.
Why? Because I must have a plug-in architecture to allow users to
create new application extensions, modules, etc. Instead of inventing a
new plug-in architecture and write yet another "how to create a DASe
plug-in" document, I simply say "here are the available Atom feeds --
mash 'em up any way you'd like" (I know, for instance, folks will want
to create fancier presentation tools than the app currently provides).
Not to mention what sorts of new & interesting combinations would occur
when my Atom consumers-that-do-interesting-things-with-my-Atom-feeds are
pointed at someone else's Atom feeds.
Any thoughts or pointers to similar approaches out there??
I don't know to what extent O'Reilly would be willing to publicly share,
but some aspects of what you describe sound like things that O'Reilly
has done with their internal APP repository which purportedly[1] holds
"hundreds of books, thousands of articles, and hundreds of thousands of
images"
- Sam Ruby
[1]
http://www.oreillynet.com/xml/blog/2007/04/atom_publishing_protocol_inter.html
