It took me (much) longer than I expected (unfortunately paid work is something you can't leave aside in these days), but finally I have a working first implementation of a pseudo-protocol based con the XML:DB API.
Usage is as follows:
1. grab xmldb.jar, put it in the lib/ directory in order to compile the
sources, build Cocoon as usually;
2. edit cocoon.xconf and go to the source-handler section. Add a
configuration like this one:
<source-handler>
<protocol name="xmldb"
class="org.apache.cocoon.components.source.XMLDBSourceFactory">
<driver type="dbxml" class="org.dbxml.client.xmldb.DatabaseImpl" />
<driver type="exist" class="exist.xmldb.DatabaseImpl" />
</protocol>
</source-handler>
3. start playing with it as you do with the cocoon:// and resource://
protocols:) Use a JDBCish URI such as
xmldb:dbxml://some.host.running.dbxml/a/collection/ or
xmldb:exist://some.host.running.exist/a/collection/aresource.xml (the
idea is that if you want to query a collection you should put a trailing
slash). The idea is that the driver actual implementation (dbxml and
exist) is looked up in the standard XML:DB URL format and the
implementing class is taken from the configuration accordingly.
As usual, please consider this as a donation to the ASF and feel free to
decide about incorporating it in Cocoon. You might want to review the
code, since this is my first implementation of a Source.
Some random thoughts about the XML:DB stuff:
1. until now the compilation of the XML:DB stuff had been conditional.
Given the fact that Apache itself will sponsor the Xindice project, I
was wondering if it could be the case to have it compiled by default:
all that needs to be done is adding xmldb.jar to the lib directory
(which is less than 9K in size).
2. Given that the XML:DB API have no support at all for metadata, it's
almost impossible to implement a caching algorithm (there is no way to
tell what is the document size or the last modification date). I was
thinking about the Avalon resource monitoring stuff, could it help in
this case?
3. The next thing to do is to add XPath support. The code foundation is
there, but an agreement is needed about the URL format. Given that an
XPath query can be run only against a collection, I was thinking about
implementing it as
xmldb:adriver://ahost/acollection/?xpath=/my/xpath/query. But I'm very
open to suggestions :)
4. If this pseudo-protocol proves to be useful and bug free the XML:DB
generators might have little or no meaning: since they haven't made it
into any RC this can be a proper timing to decide what to do with them.
Enough for tonight, I'm eagerly waiting for your feedback, expect other
patches in the days to come :)
Ciao,
--
Gianugo Rabellino
xmldbsource.zip
Description: Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
