----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, February 08, 2004 2:48 AM Subject: Re: proposals/wvcm [was: RE: Licence for slide 2.0b]
> > On 7 Feb 2004, at 14:13, Daniel Florey wrote: > > > Hi Stefano, > > first of all I want to say that I hope my mail didn't sound like an > > offense. > > Oh, not at all! But since I know how these things go and how people > believe that once somebody with a recognized visibility says something > it might be like he's speaking for the entire community. > > I just wanted to make sure everybody understood that this was *NOT* the > case and I'm just speaking for myself and wearing no hat at all. > > > As a non native speaker it is sometimes hard to find the right > > wording. I'm > > really only interested in getting things sorted out. > > I'm not a native english speaker myself so I exactly know what you mean > :-) > > But do not worry, I completely understood your question and why you > were asking it. > > > In general I'm a friend of refactoring if it is for a good intention. > > So if > > JSR 170 is really as mature as I hope it'll be, I will help to adapt > > parts > > of the core. > > If JSR 170 doesn't get traction in the industry, we, as a group, have > failed. All the vendors that are part of the expert group are committed > to implement the JCR API and I think this is real because they are > fighting over it :-) if they were faking it or didn't care, there would > be no fight at all. > > > If you say you want to put slide on top of jsr do you think of some > > kind of > > jsr170-store? > > no. I think that the Slide API should really die once JCR takes off, > but that some people might want to see that surviving, so it would be > simply a layer on top. > > Of course, a situation where we just killed the Slide API and used JCR > only as the repository API would make me very happy, but that really > depends on the community. (not that much has been built on top of the > Slide API anyway. > > As for the webdav stack, I believe it would be a fairly easy job to do > the migration between the Slide API and JCR and might even shake out > some inconsistencies in separation of concern and clean up the code. I agree totally. I had my first personal contact with the webdav methods on friday and I think (beside some things that are just a matter of taste) there is room for ceaning up the code (and making it a lot faster). > > > Is it the intention of jsr170 to get one api to access several > > legacy repositories (like notes, cvs etc) if an implementation is done? > > Oh totally. the JCR data model describes a hierarchy of items, they can > be either nodes or properties, and they can be futher extended with > custom nodetypes. It supports versioning (and it's done by the same > people that wrote DeltaV), transactions, observability, searching, > linking and access control. > > 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. What about typed properties in webdav? What about events/observation? Transactions? 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? > > 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. 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. > > 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? Or do we still need a concept comparable to slide-stores/scopes? 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? > > >>> 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. > > 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... For application developer it would be ideal if there were one api to adress repositories and the impl cares about remote or direct calls. I'm really curious which direction all this will take and look forward to have look at both JSR's! regards, Daniel > > -- > Stefano. > > > --------------------------------------------------------------------- > 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]
