...I don't understand. PUT doesn't carry any meta data (not explicitely).
Do you mean PROPPATCH?
No, but if you want to index the dead properties as well as live ones, you need to intercept PUT and either read the dead props from the backend to index them or recreate them locally.
...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.
"Afterwards" will not be suitable for all purposes, in most cases you want the index to be updated right away, if possible in the same transaction used to store the content (but this might be hard to do).
...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)....
Storing properties in a table with PROP_NAME and PROP_VALUE rows, for example, allows for arbitrary user-defined properties (unless you want to store widely varying data types, but I don't know if WebDAV has a concept of data types for properties).
...When I first heard about the idea for using Cocoon as a DASL indexing
engine I immediately thought about using Lucene for this....
Sounds interesting, but will Lucene allow efficient index updates on every PUT/PROPPATCH and similar operations, or do you have to defer indexing for later?
...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....
Yes, and even a custom DASL search language would be useful already, even if the basicsearch stuff is not implemented at first.
...Does this make sense?
It sure does - I'm just worried about how well Lucene compares to a database in terms of storing large quantities of data.
-Bertrand
