Bertrand Delacretaz wrote:
<match type="request-method" pattern="PUT"> <act type="syncmetadatadb"> <generate type="webdavproxy"> <parameter name="url" value="http://whatever/dav/{../1}"/ </generate> <serialize/> </act> </match>
I don't understand. PUT doesn't carry any meta data (not explicitely). Do you mean PROPPATCH?
No, as Bertrand said you need to sync every possible property (even live ones), so a PUT generates properties on the origin server.
You're right, we need a safer approach.
Why holding the meta data redundant at all? The meta data is already there (on the WebDAV server, even if not DASL enabled). You just need to find a way to index afterwards.
I'm with Bertrand here: afterwards might just be too late. Think about documents being deleted or whose metadata are modified (a live document being put on hold as an example). I'm now trying to understand if there is a way to implement rollback at a webdav level (a decent SQL database would have it for free, so this is not my major concern). I'm wondering if an undo operation can be applied for every WebDAV method, but this would require quite a messy transaction/redo log" maintenance on Cocoon, and I'm not sure I want to dive into that. :-)
A SQL DB would be nice to store and index a certain set of predefined properties but it falls short if you have any abitrary user-defined properties (as is the case with WebDAV).
The problem isn't really simple name-value properties as Bertrand suggested. Metadata in WebDAV are actually elements, so you need a way to query them using XML (though actually DAV:basicsearch has no such capabilities AFAIK: it seems to suppose untyped (String, String) name-value properties. So, if basicsearch is enough, an SQL DB would be just fine (as Catacomb shows).
You would need the LuceneXMLIndexer to store ALL fields (instead of just a few configured ones), as a DASL query could request all properties. You could even index content and properties side by side, as DASL may query the content itself.
But how does Lucene behave with incremental indexing?
The challenging part is to create another SearchGenerator that parses the DASL query, although it shouldn't be too hard to at least cover a basic DASL subset.
The basicsearch grammar implementation is the least problem I can imagine. It's XML, so it should be pretty easy to translate it into another domain.
If all this once is working you can easily DASL-enable any InspectableSource and it fits more nicely with Cocoon's architecture IMHO.
Oh well, that would be pure Nirvana. But it would fit in a much bigger picture: WebDAV enabled Sources with not only DASL but all the WebDAV stuff in it. Yet, I'm afraid it's a long way to go.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
