On 8 Feb 2004, at 14:35, Daniel Florey wrote:
----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Cc: "Nuescheler David" <[EMAIL PROTECTED]> Sent: Sunday, February 08, 2004 4:46 PM Subject: Re: proposals/wvcm [was: RE: Licence for slide 2.0b]
On 8 Feb 2004, at 07:31, Daniel Florey wrote:
It is, in fact, the API dual of the entire WebDAV protocol stack on the server side.
This sounds good. It would be best, if they would somethimes have a real 1:1 relation. But as far as I know today there are some things needs consolidation.
There is a great deal of functional overlap between WebDAV and JCR. But
there is at least one big difference.
Let me explain: a contract is what separates two concern islands in order to formalize SoC (separation of concerns)
[island] ---(contract)--- [island]
this contract can be anything (the shape of the electric plug, a protocol, a practice, an API). In short, a contract is what both sides take for granted and allow them to interoperate.
A solid contract allow things separation and isolation, therefore parallelization and polymorphism.
Now, this said, in client/server architectures, this contracts are directional and identify the client concern and the server one (there are few bidirectional contracts, but that's rare even if becoming more popular with p2p systems)
WebDAV, just like HTTP, is a contract with a very precise orientation: a server implements WebDAV and a client calls it. But, this tends to implicitly indicate that there will be far more clients than servers.
The Servlet API, on the other hand, (or any other module API for a web
server) started as a way to allow people to write their own modules. In
this regard, the few2many relationship is reversed: there will be much
more modules (servlets) than clients (containers).
So, the picture for http/servlets is
client -(http)-> server -(servlet API)-> servlets [many] [few] [many]
[this was the basic of the 'application server' concept that is now obsolete as a marketing term]
What is the picture for webdav/JCR? well, let's see:
client -(webdav)-> server -(JCR)-> repository [many] [few] [few]
As you see, there is a difference and this is also *the* single worst architectural weak point of the Servlet API: it's too granular!
More and more the Servlet API evolved to reduce the granularity and
more and more packaging into the API (the WAR concept, for example) and
today almost nobody writes servlets by hand but uses a framework.
So, the granularity fo the API was fixed with framework
client -(http)-> server -(servlet API)-> servlets -(framework)-> webapp
[many] [few] [many] [few]
so that can be collapsed, from the webapp point of view in
client -(http)-> server -(framework)-> webapp [many] [few] [few]
Cocoon, Struts, Turbine, Tapestry are all very different examples of the same architectural de-granularization.
This are interesting thoughts even though I think that the main advantage of
frameworks is the reusability of components. You have very fine grained
components in frameworks as well (e.g. writing actions or whatever instead
of servlets), but they might be more reusable than servlets that are very
app-specific.
Yep, you hit the nail right on the head: not only there are "few" webapps, but also frameworks drive the component oriented approach much better, ending up with 'true' reusability of components [well, some frameworks are better than others on this, but this is another story[
And as know from experience the biggest criteria for success of a technology
is simplicity.
True, that's necessary, but not sufficient.
Ok, now I think I got it. I'm very curious how this will look in detail.So, instead of having a ton of various JCR repositories and have the container handle the mapping and routing of information (in a nonstandard therefore inconsistent way!), JCR is *already* a framework for you to plug in your different nodetypes (which are the JCR closest equivalent to slide stores)
Good.
One note here: the spec originally included a way to make those
nodetypes portable across containers. This was removed because it would
have add too much complexity to the spec at this stage and we weren't
sure on how the people would have used the API, but we will probably
add it later down the road if it makes sense.
What about typed properties in webdav?
what do you mean?
What about events/observation?
Observability is an optional property of a JCR repository. Unfortunately, I must say. But some vendors can't provide that functionality. [you have to make compromises in those groups]
Transactions?
yep
What I meant was different: I thought that transaction, observability and
typed metadata (is a metadata property of type boolean, date, xpath etc.)
might be provided by the repository but don't have an equivalent in webdav.
Ah, I see.
So what I said about webdav-extensions was just an idea how to get all features of the jcr accessable via webdav.
This is not a concern of the JSR170 working group and, to be honest, I haven't thought about it, but admittedly you have a point.
As I posted in another thread I found some information on webdav-extendsions that would fill this gap (have a look at exchange 2000 sdk). Isn't MS member of wedav.org?
webdav.org is Greg Stein's own web site and has no official affiliation
with the WebDAV working groups at IETF. Yes, Microsoft was a big part
of the IETF working groups. [that's how they were supposed to screw
open source by making the protocols incredibly complex, read the
helloween documents, too bad that Greg implemented mod_dav in two weeks
and that forced them to shoot a little higher and that's how SOAP got
in the picture]
I see. But if we would come to the conclusion that something is missing in
webdav to achieve the full jcr capabilities over webdav, why not using the
MS extensions? I don't know anything about licensing in this case, but it
would have the advantage that ms-clients could talk to the jcr via webdav...
I'm sure we'll have planty of time to discuss this later down the road :-)
[snip]
There are more and more part that are included in the slide project, so I
have to paint a picture in my head to get this clear. My impression is that
slide is moving from a content repository to a webdav centric set of
applications:
Client
- webdav testsuite
- webdav client library (extending the httpclient) to access the server via
webdav (protocol centric approach)
- jsr-147 implementation to access server via webdav/deltaV with additional
functionality and higher abstraction than webdav client (more object centric
than protocol centric)
- command line client that makes use of webdav client library
Server
- server side webdav layer in front of repository (currently using slide
api, might use jsr-170 in future)
- the repository itself with the different vendor specific stores
- taglib to access slide from jsp's
+ things I've forgotten :-)
As you mentioned some time ago it might be a good idea to make Slide a top
level project to get all of this visible to the community.
yep, whenever you guys are ready I can get this started.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
