First of all let me say "thanks"! Then let me ask if you can think of any way integrating your efforts with what Christophe has already done?
I have also seen you use some JDK1.4 specific methods which might be troublesome as we decided to support 1.3 as well...
Further comments will follow inline...
Nick Reddel wrote:
Hi everyone
I have developed an indexing store (subclassing j2ee/rdbms adapter)(which indexes properties, NOT content), at the moment just for MySQL 4.1+ but presumably easily transferable to any othe RDMS that supports subselects. But...the code is horrible and undocumented, because as soon as I got it working I then moved on to a "virtual" store (i.e. a relational filesystem, which will be the sweetest thing as soon as I've sorted out some sort of leak which means the connections don't go back to the pool).
What is this virtual store? By the way, you need to close all connections to make them go back into the pool...
The reason I did some of the strange things I did, which I've marked below with (!), is that I've made a refreshing Netbeans webdav client, which for the sake of completeness needs to know if absolutely any modifications have happened to a given uri/object/file, particularly lock changes. My idea was to have a group of authors working on the same set of files, only allowing offline content changes if the file's checked out, rather than the local/remote model that's standard. I'll explain why if anyone's interested, but in another mail.
So> a few notes/queries on the implementation. I can upload my sources, but I'd need a little time to make it slightly less embarassing, and any input/critiques I can get on the solution below (architecturally I find Slide a completely impossible act to follow. Which makes me a little shy).
I agree we really need *much* better developer docs. Will you be able to contribute anything describing your experience with Slide's internals? Maybe a starting point for better docs...
Performance ----------- On my machine (a battered laptop with specs blah), the following on a folder containing 500 files getting the following, PROPFINDs equivalent:
<d:searchrequest xmlns:d="DAV:" xmlns:alx="http://www.ella-associates.org/alexis/";> <alx:multiplesearch xmlns:alx="http://www.ella-associates.org/alexis/";> <d:basicsearch xmlns:d="DAV:"> <d:select> <d:prop> <d:displayname /> <d:getcontentlength /> <d:getlastmodified /> </d:prop> </d:select> <d:from> <d:scope> <d:href>/slide/files/documents/bigf</d:href> <d:depth>1</d:depth> </d:scope> </d:from> <d:where> <d:gt> <d:prop> <d:resource-id /> </d:prop> <d:literal>0</d:literal> </d:gt> </d:where> </d:basicsearch> </alx:multiplesearch></d:searchrequest>
***alx:multiplesearch bundles a lot of search requests, which means a client wanting change info on a bunch of folders only has to send one SEARCH
PROPFIND (1st time, revisiondescriptor cache building) 16294 ms PROPFIND (2nd time, from cache) 9003 ms SEARCH 772 ms (and some of that's just the pipes waiting on each other)
Which sort of begs the question, why not allow PROPFIND to just call a SEARCH, if appropriate? (And yes, I have got classes to generate a SEARCH body).
Which also raises the question, why is PROPFIND sooo slow?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
