cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: WebDAV proxy available
Date Mon, 01 Sep 2003 21:00:09 GMT
Guido Casper wrote:

>>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

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.


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message