WebDAV client: dependences on server-side code

[Mikhail Kotelnikov <mi...@kotelnikov.com>]

Hello,

I tried to use the WebDAV client library separately from the server code 
and it was not possible - there is a lot of small dependences on the 
server-side code (constants and utility methods from the server packages 
are used directly in the client library implementation). Example: client 
depends on the servlet API only because it uses some constants from 
HttpServletRequest/HttpServletResponse...
I think it would be great to have the following dependency structure:
- dav common library (constants, utility methods, ...)
    - dav server
    - dav client
What do you think?

Best regards,
Mikhail

Re: WebDAV client: dependences on server-side code

[Brian Moseley <bc...@osafoundation.org>]

On 4/11/06, Angela Schreiber <an...@day.com> wrote:

> once we have cleaned this up, we could finally have the
> webdav-libarary (plus example implementation) called
> 'jackrabbit-webdav' and have the remoting stuff called
> 'jcr-server' only (or find a good name for the latter
> as well).

good deal.

Re: WebDAV client: dependences on server-side code

[Angela Schreiber <an...@day.com>]

hi mikhail

> I tried to use the WebDAV client library separately from the server code 

your are talking about the 'client' project having a dependency
to the 'webdav' project, aren't you?

actually, the aim of the 'webdav' project was not to provide
a library for server specific code. instead is should act as
as webdav library. but you are right, that there exists the
dependency to the servlet api which is useful for the server
side only.
or the other way round: if the dav-library is not meant to
be 'server' specific, the client-method classes currently
present in the 'client' module should be part of the
library as well. the reason for this is, that i don't consider
those client-methods to be finished (and i did quite some
refinement on them, which i did not commit yet).

> I think it would be great to have the following dependency structure:
> - dav common library (constants, utility methods, ...)
>    - dav server
>    - dav client
> What do you think?

yes, agreed.
but this would require yet another reflection about
the project structure of the jcr-server, since the 'server'
project currently contains the server-side implementations
and not the server library.

i'm currently thinking about the latter due to the fact,
that the 'simple' server is getting complex and based
on the experience, that the remoting part ('jcr-server')
should be kept in a different place in order to avoid
confusions between 'webdav' server and the attemt to
build a jcr-client which talks to the server via webdav
(just be coincidence ;).

once we have cleaned this up, we could finally have the
webdav-libarary (plus example implementation) called
'jackrabbit-webdav' and have the remoting stuff called
'jcr-server' only (or find a good name for the latter
as well).

kind regards
angela