WebDAV implementation

[Natalia Shilenkova <ns...@gmail.com>]

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.

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

What do you think? Any other ideas, objections?

Regards,
Natalia

Re: WebDAV implementation

[Natalia Shilenkova <ns...@gmail.com>]

On 5/9/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
> > 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.

Well, most of the time record itself is not needed, but to find out
the content type of the resource filer has to read entire record just
because inline meta data is stored inside the record. To change that
means totally changing the way inline meta data is handled.

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

Are you proposing that requests for meta data should always return
merged information from both sources? I see no problem implementing
that. I wonder if there is a need to have a method to read object meta
data without reading custom document that may be stored in meta data
collection, just to save some time on reading and parsing extra
information.

Natalia

Re: WebDAV implementation

[Vadim Gritsenko <va...@reverycodes.com>]

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