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
