"Ian Kallen " wrote:
> On Wed, 22 Aug 2001, Dirk Verbeeck wrote:
> > You could move the client webdav code to commons, but the same applies to the
> > slide engine, it's also a component that is being used without the webdav server
>
> Last I checked, slide is an application (cms), whereas http and webdav are
> infrastructural (protocols). So there really is a big difference.
>
> > I don't know the reason why the http methods were separated from the webdav
> > methods but I'm sure it was for a reason... I'm find it strange that now (2-3
> > months later), you and Rodney say: lets integrate them into one project... That's
>
> I won't speak for Rodney but I wasn't following slide. I've done content
> management stuff for years, I recognize what it's trying to accomplish and
> even respect the design aspects that I disagree with but I need http and
> dav client support, not all of the higher level services that slide
> provides.
>
> > what we had a couple of months ago. A full client with httpmethods and webdav
> > methods in one distribution. (webdavlib.jar included then the http methods as
> > well).
> >
> > Maybe moving HttpClient to commons was a mistake and we should have kept
> > everything in one place.
> > Having 2 distributions seems confusing...
>
> No, what's confusing is maintaining infrastructural bits with application
> bits. An application that manages content and metadata should not be
> bound by the protocol layers that support it and vice versa; ergo, they
> should be maintained independently. I could see why you'd separate
> the http and dav clients, making a distinction between standard http and
> http extensions seems arguably reasonable. Putting httpclient and
> webdavclient in commons makes a good deal of sense: they'd be decoupled
> from the application and therefore more likely to be exercised and
> developed independently. Let protocols be protocols and applications be
> applications.
Let me quote my own mail from yesterday and explain it a bit more (see also
http://jakarta.apache.org/slide/)
Slide distribution has 3 main parts
* Slide Engine + Data Stores
The real CMS, an engine for manipulation structures, enforcing security,
versioning, locking, user management, ...
You can use this engine in client applications, inside an EJB server or
wherever you need a CMS engine.
It has interfaces to different data stores (memory, file, jdbc,...)
You can also change different parts of the engine (provide you own security
implementation/algorithm)
* Slide Webdav Server (Servlet)
Webdav protocol server support
Written as a servlet and for now only usable if you include a slide engine but
you are able to extend this servlet
and delegate the processing of Webdav requests to your own implementation.
* Slide Webdav Client API
- HttpClient + HttpMethods (connection management + support for http protocol),
this part was moved from slide to common
- WebdavMethods (support for webdav protocol from client)
- WebdavResource (gives you a WebdavFile object on a WebdavServer mutch like
the File object on a lokal file system)
There is also:
* A command line client that uses the client API and allows you to display/test the
client-server protocol.
* WebDAV enabled Swing components and application
* Examples for the 3 parts (using the engine, extending the servlet, using the client
API)
* There is also a javax.management interface for the engine. (maybe not up-to-date)
* Example deployment of "Slide Webdav Server" on tomcat.
* Tomcat Ream (user validation using the slide engine to connect to a security store)
...
About your statement:
"An application that manages content and metadata should not be
bound by the protocol layers that support it and vice versa;"
The slide project takes a different approach, and I agree with it and that is:
integrate you data sources on the server using a (slide) engine.
For now we only supply a WebDAV interface but as I said you can create your own
interface on the engine.
(any) Webdav client -> webdav interface -> slide engine -> jdbc store
normal browser -> web application (JSP, taglibs) -> slide engine ->
memory store
EJB application -> slide bean interface -> slide engine -> JNDI store
JNDI client -> JNDI provider interface -> slide engine -> custom database store
...
My experience with CM clients is that its easier to integrate different protocols
and/or backends on the server because if you do that all kinds of clients can access
all kinds of data. The clients are also easier to write, you just use one client API
and not multiple. On the server you only have 2 translations/implementation: server
interface-> engine and engine->store.
An implementation of a Webdav Client protocol independent of the Webdav server
implementation (only using the specs) has some advantages and I'm not against it, if
Rodney or you would do something like that but personaly I like the current way of
doing things (client and server implemented by the same persons and managed as one
project).
Dirk
