----- 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. And as know from experience the biggest criteria for success of a technology is simplicity. > > 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) Ok, now I think I got it. I'm very curious how this will look in detail. > > 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. So what I said about webdav-extensions was just an idea how to get all features of the jcr accessable via webdav. > > > 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... > > >> These items in the hierarchy can be really anything. They can make > >> JDBC > >> connections to a database, IIOP connections to a satellite system and > >> grab the latest weather image, talk to CVS, of your file system, or > >> LDAP server, or XML database, you name it. > >> > >> The idea is that vendors will standardize on this API to split their > >> software offers in two: the presentation layer and the data layer. > >> > >> Don't get me wrong, this won't replace RBDMS for the data that is > >> purely relational or for things like EJB or other object-relational > >> mappers, but for all sort of semi-structured data, we hope that JCR > >> will find a nice place. > >> > >> The big thing that we are still discussing is what query language to > >> use. One of the suggestions is to use DASL basicquery for now and see > >> what happens out of XQuery, since we'll provide a transparent XML view > >> of the item hierarchy that you would be able to query on very > >> granularely. > > > > As the discussions in slide-dev showed, it is really a sophisticated > > task to > > find a good solution for queries. > > yep > > > I think it is a way to go to provide one simple basic search (to allow > > standard search over different repositories) plus repository/index > > specific > > search. > > we are converging toward that as well. fine! > > >> Anyway, we should be out in public review very soon now and I expect > >> this to come up during the public review period, so I'll let you all > >> know when that happens so that you can give us feedback where you > >> think > >> we are doing something wrong > >> > >> Believe me, the group is very nice and we are really open to > >> suggestions. > >> > >>> If so I see the benefit for such an api. > >> > >> Good > >> > >>> We could enable access to all of this repositories with just building > >>> one > >>> jsr170-store. But maybe I got it wrong again... > >> > >> I would think that Slide should become *the* JCR implementation, much > >> like Tomcat is for the Servlet API. So, what tomcat does for the web, > >> Slide would do for WebDAV and JCR. > >> > >> This my hope and lots of folks in the expert group would love to see > >> that happening, because that would create a market for more fancy > >> solutions. > >> > >>> Is jsr170 more a set of interfaces or does it implement some logic as > >>> well > >>> (e.g. mounting of different stores, configuration) > >> > >> It's mostly a contract, so it's a set of interfaces, classes and it > >> includes a hierarchy of nodetypes that all containers are supposed to > >> have (this gives some solidity to the searchability of the data model) > > > > If I want to have a mixed repository (user=LDAP, some > > files=Filesystem, some > > other files=DB etc) can this be achieved by nodetypes that are mapped > > to > > different vendor implementations? > > yes, that's the idea. > > > Or do we still need a concept comparable to slide-stores/scopes? > > No, not really. As I explained above, this would strongly limit your > ability to move your data from one repository vendor to another, unless > even the mapping/configuration details were specified. > > True that there is no way to move the nodeTypes across the containers, > so it won't be possible anyway with this version of the spec, but, > architecturally, it would be easier to add in the future. [or, at > least, that's how I see it] So we should be the first to implement the jsr-170 api so that vendors will add their nodetypes to slide ;-) > > > Something like (server side only): > > > > JCR (LDAP impl) > > webdav->JCR (Slide impl with scope config) < JCR (Filesystem impl) > > > > JCR (RDBMS impl) > > > > Or how can we take advantage of the vendor specific JCR-impls without > > loosing the mixed repository feature? > > eh, good question. The architectural idea is that you have only one JCR > implementation and all the various mapping are done inside by the > various nodeTypes. Just like you don't have several Struts talking but > one that includes everything you need for that webapp. > > The way you mount, install, configure nodeTypes will be > container/specific though. Meaning that you might be able to migrate > your data from one vendor to another, but not the functionality > transparently. > > In the future, we expect to be able to do that as well. but political > interests might block this. > > >>>>> What exactly is the target of jsr-170? Is not webdav the standard > >>>>> to > >>>>> access > >>>>> a content repository? > >>>> > >>>> webdav is a protocol, JCR is an API. the parallel that comes to mind > >>>> would be HTTP and the Servlet API. > >>>> > >>>>> JSR-147 seems to be the standard to access a content > >>>>> repository via java api. > >>>> > >>>> Yes, client side. > >>>> > >>>>> So what is the use case for jsr-170 api? > >>>> > >>>> server side. > >>>> > >>>>> Is it only > >>>>> the webdav layer or is there any imaginable server side application > >>>>> that > >>>>> needs to access the repository via jsr-170? > >>>> > >>>> there are multiple scenarios. > >>>> > >>>> 1) embedded > >>>> > >>>> application -(JCR)-> repository > >>> > >>> I'm just curious if you have server side application in mind that > >>> needs > >>> access to a content repository but has no need to be clusterable. > >> > >> Oh, my blog, for example :-) > > > > :-) > > > >> > >> No, serious, all sort of micro-content management doesn't require > >> clusterization nor complex architectures. > >> > >>>> pro: speed > >>>> con: architectural flexibility > >>>> > >>>> 2) remote (via RMI) > >>>> > >>>> application -(JCR)-> -(RMI)-> repository > >>>> > >>>> pro: improved architectural flexibility (many application can access > >>>> the same repository) > >>>> con: speed, only java application can access it > >>>> > >>>> 3) remote (via webdav) > >>>> > >>>> application -(JCR)-> Webdav client -(WebDAV)-> Webdav server > >>>> -(JCR)-> > >>>> repository > >>> > >>> Did you mean > >>> application -(JCR147)-> Webdav client -(WebDAV)-> Webdav > >>> server -(JCR170)->repository > >>> ? > >> > >> No, I really meant JCR. > >> > >> [please, keep in mind that JSR and JCR are too different things: JSR > >> stands for Java Specification Request, while JCR stands for Java > >> Content Repository (here I normally omit API)] > > > > Sorry- I mixed this up. > > No problem. Just wanted to outline this because people might get > confused as well. Thank you. > > >> Imagine a scenario where you start with > >> > >> application -(JCR)-> repository > >> > >> then you want to migrate to a clutered environment. You don't want to > >> move from 170 to 147, that wouldn't make any sense. > >> > >> If you already know that you are going to be targetting a webdav > >> server, then 147 is for you, but if what you care is just a > >> repository, > >> then 170 is the way to go. > >> > >> I admit there is some overlap and that it's unfortunate that the way > >> the JCP works doesn't really allow for technology to converge and > >> reduce overlap. > >> > >>> This is my favorit approach as it allows easy clustering for the > >>> application. > >> > >> Then go for it. JCR is not designed to be a client-side API, but it > >> could be used to decouple thru a WebDAV tunnel, even if, admittedly, > >> JSR147 is probably a much more elegant way of doing it. > > > > I'm still confused as I sometime ago thought that JSR 147 only > > focusses on > > deltav-client stuff (so that it would be ideal suited for IDE vcs > > integration). Now I have the impression that both jsr's will totally > > overlap > > if they are finished... > > I don't think so (especially as the spec lead of 147 is a very active > member of 170) but I admit that I don't know 147 well enough to outline > the overlap precisely. > > > For application developer it would be ideal if there were one api to > > adress > > repositories and the impl cares about remote or direct calls. > > Yeah, I know. > > > I'm really curious which direction all this will take > > mee too :-) > > > and look forward to have look at both JSR's! > > Hopefully that will happen soon. > > -- > Stefano. 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. regards, Daniel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
