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.
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.
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.
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)
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)]
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.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
