cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <>
Subject Re: WebDAV proxy available
Date Mon, 01 Sep 2003 19:06:08 GMT
Gianugo Rabellino <> 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?

>> I think the webdav backend is much more likely to fail than
>> syncmetadb in such cases (due to insufficient authorizations etc),
>> which would create inconsistencies between the backend and meta db
>> if the sync is done with actions.
> 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.

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

When I first heard about the idea for using Cocoon as a DASL indexing
engine I immediately thought about using Lucene for this.

You would need any collection respond to a GET request with a XML
representation as the TraversableGenerator generates. The links view
applies an additional XSLT stylesheet:

    <map:view from-position="TraversableGenerator" name="links">
      <map:transform src="2htmlLinks.xsl"/>
      <map:serialize type="links"/>

So the whole WebDAV repository can be crawled by Lucene.
And Lucene's content-view-query is configured as

with the "properties" view being

    <map:view from-position="content" name="properties">
      <map:transform type="source-props"/><!--reading props-->
      <map:serialize type="xml"/>

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.

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.

If all this once is working you can easily DASL-enable any
InspectableSource and it fits more nicely with Cocoon's architecture

Does this make sense?


View raw message