jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Status of jcr-server
Date Tue, 04 Apr 2006 14:01:35 GMT
hi julian

> First step was to run the generic test suite Litmus 
> (<http://www.webdav.org/neon/litmus/>), which currently reports a range 
> of failures, 

i let litmus run a couple of times in the past and send
the commented results to the list:

1) initial litmus result.
    that post also explains, why PROPPATCH fails with the
    default setup: by default non-collection resources represent
    jcr nodes with nodetype nt:file. This nodetype does not allow
    to set random properties.

http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg02792.html

2) a more recent test (after reworking the dav-library while
    getting rid of JDOM)

http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg04037.html

> some of which seem to be trivial (non wellformed request 
> bodies not rejected with status 400), 

brian originally posted findings resulting from litmus
tests. at that time we decided, that we try to work around
invalid xml within PROPFIND although this is not compliant
with the RFC. if i'm not mistaken, there is still a 'todo' in
the webdav-request impl class.

> some not (such as If header evaluation problems, 

this one i missed so far :)

> PROPPATCH tests all failing).

see 1)

> In the mid-term, I'd like to contribute to jcr-server, both in fixing 
> compliance problems, but also in adding features (Redirect support? 
> Property datatype support). 

sounds good. there is couple of other things missing in the
library, where you could contribute.

> For now, what's the best way to start? 

since there is almost no documentation except for things
discussed within this mailing list, you may start looking
at the code.

> If I'm sure I found an actual problem in the code, should I open a bug 
> report over at <http://issues.apache.org/jira/browse/JCR>, then try to 
> provide a patch?

yes please.

> Also, what are the current goals for jcr-server? Is it just a 
> proof-of-concept, or is it supposed to become a fully compliant 
> implementation of the applicable RFCs? Is it supposed to follow the 
> changes in RFC2518bis as well?

at the very beginning the aim was to provide a 'simple'
dav-view to a JSR170 compliant repository (that what we
still call the 'simple server') as well as a webdav
remoting for a JSR170 repository (the 'jcr-server').

the webdav library which does not have any dependencies
to the jcr-api was just a side-effect of the efforts
made for the server implementations... in the meantime
we put some work into the library, to improve compliance
with the various webdav RFCs.

regarding compliance of the 2 implementations:

a) jcr-server: since the aim of this impl is to provide
    remoting of the jsr170 api; compliance to dav-RFC is
    fine but not the primary goal.

b) simple-server: compliance it definitely required.
    however, the supported feature-set is forced by the
    underlying repository. its not the dav-implementation that
    builts or govers the data storage. i guess, this has been
    the source of some misunderstanding in the past.
    currently the simple-server only implements compliance
    levels 1,2. jeremi planned to add additional functionality
    to the simple server.


for further information regarding aims and current status
of the jcr-server see the following posts:

http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03658.html
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03693.html
http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03762.html

kind regards
angela

Mime
View raw message