In a post entitled "Column Stores". Bruno Dumon considers switching database platforms for the
cocoon-based Daisy CMS repository (which we have used for several years now at scrutable).
http://brunodumon.wordpress.com/2007/10/07/column-stores/
He mentions some different XQuery offerings such as MonetDB (which looks cool), and there are
several comments from Bruno's readers suggesting other XQuery implementations.
But, regardless of how great MonetDB or Sedna or other open source XQuery implementations
are, I'm pretty sure they're not integrated with cocoon out of the box.
As someone who uses Daisy, cocoon, and eXist, it seems to me that the best Daisy repository
forward migration is onto the (somewhat unfortunately named, google-wise)
eXist DB
Why? because
1) Both Daisy and eXist use Apache Cocoon (which of course is pure java).
2) One of eXist's strengths is its GUI remote-admin client, which allows us to easily manage and query
documents and collections in what I think is a highly daisy-compatible way. (It allows me to manage
and query documents in my home-grown apps better than in my CMS - daisy - and I want to fix that!).
3) eXist offers a multitude of other interfaces (java API, REST, XMLRPC, SOAP, WebDAV, REST).
So, I see a golden opportunity for a clean, lightweight integration of the two apps. I recognize that
Daisy currently uses a lot of other infrastructure besides cocoon, such as messaging and BPM stuff in
ActiveMQ, but from practical experience I think that at least the option of a lighter Daisy deployment
would be a good thing. Personally, I see the BPM/workflow as an almost entirely a separate app from
the CMS, which should only need to be turned on for "enterprise daisy", but others may see things
differently.
Also, there is a whole discussion here to be had around the relationship between metadata and
content, XML and RDF and SQL, etc., but I don't want to get bogged down in that just now.
My point is that I would love to be able to run daisy-lite and eXist in a single JVM, configured using
little more than the two cocoon sitemaps, probably deployed inside the same cocoon instance
(eventually, I suppose, as cocoon "blocks", which the eXist project already delivers).
Any required enterprise messaging/BPM infrastructure could be bolted on to the same JVM, or run in
a separate process (ActiveMQ, Mule, whatever). Application components shouldn't care what container
they are running in - SOA basics, right?
(Details of how I would approach this migration task are behind the cut).
If achieved, then in the simple let's-get-started use-case for Daisy+eXist, there's
only one OS process to (re)start to run both projects (the servlet container under which
the cocoon apps run). This single process yields a pure-java, XQuery-compliant content
management system that provides interfaces for remote editing (through Daisy Wiki),
remote management (through eXist java admin client), and remote query (through XQuery
on eXist + any chosen bonus metadata storage/query infrastructure). And hey, eXist also
supports WebDAV, which would be a nice way to move Daisy documents around, too.
IJust as important as all that out-of-the-box functionality, that hypothetical CMS+repository
is straightforward to extend and integrate in the web tier, using cocoon.
Finally, the uniting of the Daisy and eXist apps as closer cousins in the cocoon family would, I think,
strengthen the cocoon platform and help to justify increased investment and sponsorship for all three
projects. Thoughts?
Continue reading "Well, the Daisy CMS and eXist XQuery DB *are* both coccon apps..." »
