Re: WebDAV implementation

Natalia Shilenkova wrote:
> Hi all,
> 
> While working on Webadmin, I found that existing Xindice code may need
> some modifications in order for WebDAV implementation to work more
> efficiently.
> 
> 1. According to WebDAV specification, methods such as PUT, COPY, or
> MOVE must return different codes depending on previous existence of
> the target resource. COPY and MOVE methods also have an option that
> specifies if existing target resource can be overwritten. Because of
> multithreading, to follow the specification most of the WebDAV methods
> have to be synchronized, which is bad for performance. Alternatively,
> class org.apache.xindice.core.Collection may provide some additional
> functionality.
> 
> Though currently Collection has methods insert() and set(), they are
> not really different and not enforced (looks like they were more
> separated in the past). My suggestion is to change them so insert()
> throws fault code if that key already exists in database and set()
> inserts the resource if it is a new key or replaces existing resource.
> It will help to resolve the problem with minimal changes in the
> existing code.

Sounds good. In this case XML:DB Collection.storeResource() should be mapped to 
the set(); it curently uses insert() in the embedded driver.


> 2. Creation and modification time for the resource can be accessed
> from both filer record information and meta-data collection, but using
> meta-data collection means client have to access two collections
> instead of one for no reason.

Does the client needs only meta data, or both meta data and object data 
(document/binary)?

If you want to retrieve meta data only -- like modification time -- retrieving 
complete record, with data, would be less efficient than retrieving meta data only.


> The only problem that Collection class
> does not provide a way for its clients to get this information, when
> Collection reads record from a filer, it discards everything except
> record value.
> 
> Well, what if Collection's method getEntry() returns not just an
> object, but some additional information it gets from the filer? Return
> type would be an instance of a class that is similar to class Record,
> but more high-level, so client can get basic resource properties
> without making another round trip to database.

Yes this sounds good. There is creation/modification time on filer level which 
is not exposed properly through collection.

I think I'd even prefer several variations of this method to cover different 
usecases:
   * Retrieve meta data only
   * Retrieve object data only
   * Retrieve both meta data and object data

First one would need two hits -- read filer record [Note 1] and read additional 
meta data from meta data collection. Second requires only one hit to filer, and 
third -- again two hits. WDYT?

Note 1: When retrieving filer meta data only, it would be nice to let filer know 
that it should only read first page of the value, and should not read complete 
value into the memory -- if all you need is creation/modification time, reading 
complete value can be a significant performance hit.

Vadim

> What do you think? Any other ideas, objections?
> 
> Regards,
> Natalia