Re: Slide and JSR170
Slide does not support JRS170. Jackrabbit isn't used either. It's the other way round as well, Jackrabbit does not use Slide either. I guess there are quite a number of parameters included in the decision which way to go, so I really can not make any recommendation. Good thing about WebDAV is that there already are a number of applications supporting it. Drawback would be that WebDAV by nature is a client/sever protocol, so you would always have the communication overhead. On the other hand while JSR170 covers only certain aspects of a content store, WebDAV is pretty much complete. Additionally, programming against JSR170 would restrict you to Java solutions. I *personally* would not at all recommend programming against the sever Slide API... Oliver On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > Ok, simple question. Is the Slide API based on JSR170 ? If so, is > JackRabbit used inside Slide ? We are considering if we should write our > java clients to use WebDAV client protocols or use the Slide API, or if > possible the 170 api. > > Any guidance would be appreciated. > > Jeff > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide and JSR170
Thanks for the response. I quess my question is, "What is the overall architecture for CMS as far as Apache goes ?" There seems to be quite a bit of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. They seem like the logical stack. I agree with your assessment re: webdav. It is more global in nature. Just curious, why do you recommend against using the server Slide API. Is it because it is only relevant to slide ? If so, I agree, because it causes technology lockin. So, if that is the case, what is the benefit of the server api at all ? Jeff -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:08 PM To: Slide Users Mailing List; [EMAIL PROTECTED] Subject: Re: Slide and JSR170 Slide does not support JRS170. Jackrabbit isn't used either. It's the other way round as well, Jackrabbit does not use Slide either. I guess there are quite a number of parameters included in the decision which way to go, so I really can not make any recommendation. Good thing about WebDAV is that there already are a number of applications supporting it. Drawback would be that WebDAV by nature is a client/sever protocol, so you would always have the communication overhead. On the other hand while JSR170 covers only certain aspects of a content store, WebDAV is pretty much complete. Additionally, programming against JSR170 would restrict you to Java solutions. I *personally* would not at all recommend programming against the sever Slide API... Oliver On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > Ok, simple question. Is the Slide API based on JSR170 ? If so, is > JackRabbit used inside Slide ? We are considering if we should write > our java clients to use WebDAV client protocols or use the Slide API, > or if possible the 170 api. > > Any guidance would be appreciated. > > Jeff > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide and JSR170
I don't think jsr 170 forms a logical stack for Slide - who's primary concern is WebDAV protocol implementation. I am very skeptical of jsr 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, HP, Borland aren't exactly companies I think of when considering content management systems. I think this is another example of the jcp's callous disregard for what already exists. Webdav, Delta V, ACL, WebDAV-search etc. already exist as standards in a language neutral way. Instead of specifying a java API that basically uses java native method calls in lieu of http, they've created a whole parallel spec set. What a waste ... - Original Message - From: "Jeff Broberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "'Slide Users Mailing List'" <[EMAIL PROTECTED]> Sent: Tuesday, November 30, 2004 7:56 PM Subject: RE: Slide and JSR170 > Thanks for the response. I quess my question is, "What is the overall > architecture for CMS as far as Apache goes ?" There seems to be quite a bit > of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. > They seem like the logical stack. I agree with your assessment re: webdav. > It is more global in nature. > > Just curious, why do you recommend against using the server Slide API. Is > it because it is only relevant to slide ? If so, I agree, because it causes > technology lockin. So, if that is the case, what is the benefit of the > server api at all ? > > Jeff > > -Original Message- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 6:08 PM > To: Slide Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Slide and JSR170 > > Slide does not support JRS170. Jackrabbit isn't used either. It's the other > way round as well, Jackrabbit does not use Slide either. > > I guess there are quite a number of parameters included in the decision > which way to go, so I really can not make any recommendation. > > Good thing about WebDAV is that there already are a number of applications > supporting it. Drawback would be that WebDAV by nature is a client/sever > protocol, so you would always have the communication overhead. On the other > hand while JSR170 covers only certain aspects of a content store, WebDAV is > pretty much complete. Additionally, programming against JSR170 would > restrict you to Java solutions. > > I *personally* would not at all recommend programming against the sever > Slide API... > > Oliver > > On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > > Ok, simple question. Is the Slide API based on JSR170 ? If so, is > > JackRabbit used inside Slide ? We are considering if we should write > > our java clients to use WebDAV client protocols or use the Slide API, > > or if possible the 170 api. > > > > Any guidance would be appreciated. > > > > Jeff > > > > > > > > - > 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]
RE: Slide and JSR170
Just some food for thought to help protect your software from this duplication... If I were to start from scratch (not that I would) I would create an architecture that uses both in a multi-layered fashion. On the java client side (e.g. Swing) I would: - wrap a webdav api (e.g. slide) with the jsr170 api - this allows the client to access any webdav server - allows swapping jsr170 implementations - allows for swapping client-side CM tools that are used locally and don't need http. I think this is along the lines of jsr-147. On the server side I would: - expose the external facing/remote interface using webdav - this allows existing clients to access it - it also allows streaming large files over http which is more scalable then the non-streaming rmi alternative - internally I would use the jsr170 api so I don't have to define my own - the server could also act as a webdav client and use the wrapper mentioned above I use this logical architecture as a reference model when I need to decide what to use where and to help protect/decouple me from those choices. - John -Original Message- From: Jeff Broberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:57 PM To: [EMAIL PROTECTED]; 'Slide Users Mailing List' Subject: RE: Slide and JSR170 Thanks for the response. I quess my question is, "What is the overall architecture for CMS as far as Apache goes ?" There seems to be quite a bit of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. They seem like the logical stack. I agree with your assessment re: webdav. It is more global in nature. Just curious, why do you recommend against using the server Slide API. Is it because it is only relevant to slide ? If so, I agree, because it causes technology lockin. So, if that is the case, what is the benefit of the server api at all ? Jeff -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:08 PM To: Slide Users Mailing List; [EMAIL PROTECTED] Subject: Re: Slide and JSR170 Slide does not support JRS170. Jackrabbit isn't used either. It's the other way round as well, Jackrabbit does not use Slide either. I guess there are quite a number of parameters included in the decision which way to go, so I really can not make any recommendation. Good thing about WebDAV is that there already are a number of applications supporting it. Drawback would be that WebDAV by nature is a client/sever protocol, so you would always have the communication overhead. On the other hand while JSR170 covers only certain aspects of a content store, WebDAV is pretty much complete. Additionally, programming against JSR170 would restrict you to Java solutions. I *personally* would not at all recommend programming against the sever Slide API... Oliver On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > Ok, simple question. Is the Slide API based on JSR170 ? If so, is > JackRabbit used inside Slide ? We are considering if we should write > our java clients to use WebDAV client protocols or use the Slide API, > or if possible the 170 api. > > Any guidance would be appreciated. > > Jeff > > - 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]
Re: Slide and JSR170
kranga wrote: I don't think jsr 170 forms a logical stack for Slide - who's primary concern is WebDAV protocol implementation. I am very skeptical of jsr 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, HP, Borland aren't exactly companies I think of when considering content management systems. I think this is another example of the jcp's callous disregard for what already exists. Webdav, Delta V, ACL, WebDAV-search etc. already exist as standards in a language neutral way. Instead of specifying a java API that basically uses java native method calls in lieu of http, they've created a whole parallel spec set. What a waste ... Well, I don't think we're talking about the same things here. Just because there's SQL, it doesn't mean we don't need JDBC. They are two different things, WebDAV is a protocol with an underlying model, as you say language neutral. But to work with it from within a language like java we need an API. Or else how do you communicate with a WebDAV server from Java. That's why there's slide-webdavclient, or the slide internal server API. That jsr170 parallels some of the concepts of WebDAV and related tools is only natural but it's not a replacement, you can use jsr170 as the java webdav client API or you can put WebDAV on top of a jsr170 repository server to expose it remotely. I see it as the same difference as LDAP/JNDI or SQL/JDBC or XML/SAX/DOM etc. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert <[EMAIL PROTECTED]> wrote: > - wrap a webdav api (e.g. slide) with the jsr170 api This has been discussed as in option inside Slide. If you plan to implement something like that would you consider donating it to Slide? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide and JSR170
On Tue, 30 Nov 2004 19:56:44 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > Thanks for the response. I quess my question is, "What is the overall > architecture for CMS as far as Apache goes ?" There seems to be quite a bit > of duplication, and I am not sure why slide wouldn't use jackrabbit, or 170. 1) Slide was there long before there even was the JSR170 or Jackrabbit, so it can hardly rely on it 2) You do not actually *use* JSR170 but at most expose it as an API to the programmer 3) I do not think there is something like a master plan concerning CMS architecture at Apache > Just curious, why do you recommend against using the server Slide API. Is > it because it is only relevant to slide ? If so, I agree, because it causes > technology lockin. So, if that is the case, what is the benefit of the > server api at all ? It is not because it is proprietary. You could easily put something like an abstraction wrapper around it or use any form of data access ojects. The reason is that it is pretty hard and error prone to program to the Server API. So, do not program to it if you do not have to. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide and JSR170
To do this you will need to perform a major 'gap-analysis' exercise. The
functionality that is specified by the WebDav & JCR specifications are
basically over-lapping sets, i.e. the functionality of neither specification
is a subset of the other but there are significant degrees of overlap.
>From my cursory introduction (I have been using both Slide and JCR170 for
about 3 months) the following areas spring to mind:
JCR Implementation
* - includes version control that allows you to roll back to a named
previous version.
* - Node Type definitions. All nodes are related to a node type that
defines the details of attributes that can be assigned to that node and can
be used to restrict the type of children that can be attached.
* - XML Import & Export of Node hierarchies
WebDav Implementation
* - Ability to assign privileges to nodes (JCR spec deliberately excludes
this but does allow you to check if the user has appropriate privilege)
{ I am sure that there are other features that are in WebDav/DeltaV but not
in JCR170 but I am using the Slide Server API directly and found that Oliver
is right in saying that it's not a task to be undertaken lightly :) }
HTH
Andy Bowes
NB : Public release of JCR170 also includes the ability to have multiple
parents for a specific node
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: 01 December 2004 10:06
To: Slide Users Mailing List
Subject: Re: Slide and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert <[EMAIL PROTECTED]>
wrote:
> - wrap a webdav api (e.g. slide) with the jsr170 api
This has been discussed as in option inside Slide. If you plan to
implement something like that would you consider donating it to Slide?
Oliver
-
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]
RE: Slide and JSR170
Personally, I like the WebDav layer ontop of JSR170. I still feel that Slide should expose jsr170 as one of its stores, so that it can have relevance in the long term. I can understand using webdav to access the content from the client, but to build out a web based management console ontop of the repository, I do not want a proprietary api ( aka slides ), I would prefer a standard. At that is where I see 170 being important. jeff -Original Message- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 12:39 AM To: Slide Users Mailing List Subject: Re: Slide and JSR170 kranga wrote: > I don't think jsr 170 forms a logical stack for Slide - who's primary > concern is WebDAV protocol implementation. I am very skeptical of jsr > 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, > HP, Borland aren't exactly companies I think of when considering > content management systems. I think this is another example of the > jcp's callous disregard for what already exists. Webdav, Delta V, ACL, > WebDAV-search etc. already exist as standards in a language neutral > way. Instead of specifying a java API that basically uses java native > method calls in lieu of http, they've created a whole parallel spec set. What a waste ... Well, I don't think we're talking about the same things here. Just because there's SQL, it doesn't mean we don't need JDBC. They are two different things, WebDAV is a protocol with an underlying model, as you say language neutral. But to work with it from within a language like java we need an API. Or else how do you communicate with a WebDAV server from Java. That's why there's slide-webdavclient, or the slide internal server API. That jsr170 parallels some of the concepts of WebDAV and related tools is only natural but it's not a replacement, you can use jsr170 as the java webdav client API or you can put WebDAV on top of a jsr170 repository server to expose it remotely. I see it as the same difference as LDAP/JNDI or SQL/JDBC or XML/SAX/DOM etc. Carlos - 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]
Re: Slide and JSR170
It was my understanding that JSR170 is still immature. It is not a final
spec. Coding to an unfinished spec is not worth the risk, imho. We chose to
use slide, aside from the obvious webdav support (versioning, locks,
role-based security, etc...) because slide supports cache invalidation and
clustering with its new 2.1b. Implementing this feature-set with the
incomplete JSR170 is not an option for us.
Roy Russo
JBoss Portal Developer
- Original Message -
From: "Andy Bowes" <[EMAIL PROTECTED]>
To: "'Slide Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 01, 2004 5:33 AM
Subject: RE: Slide and JSR170
To do this you will need to perform a major 'gap-analysis' exercise. The
functionality that is specified by the WebDav & JCR specifications are
basically over-lapping sets, i.e. the functionality of neither
specification
is a subset of the other but there are significant degrees of overlap.
From my cursory introduction (I have been using both Slide and JCR170 for
about 3 months) the following areas spring to mind:
JCR Implementation
* - includes version control that allows you to roll back to a named
previous version.
* - Node Type definitions. All nodes are related to a node type that
defines the details of attributes that can be assigned to that node and
can
be used to restrict the type of children that can be attached.
* - XML Import & Export of Node hierarchies
WebDav Implementation
* - Ability to assign privileges to nodes (JCR spec deliberately excludes
this but does allow you to check if the user has appropriate privilege)
{ I am sure that there are other features that are in WebDav/DeltaV but
not
in JCR170 but I am using the Slide Server API directly and found that
Oliver
is right in saying that it's not a task to be undertaken lightly :) }
HTH
Andy Bowes
NB : Public release of JCR170 also includes the ability to have multiple
parents for a specific node
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: 01 December 2004 10:06
To: Slide Users Mailing List
Subject: Re: Slide and JSR170
On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert <[EMAIL PROTECTED]>
wrote:
- wrap a webdav api (e.g. slide) with the jsr170 api
This has been discussed as in option inside Slide. If you plan to
implement something like that would you consider donating it to Slide?
Oliver
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide and JSR170
AFAIK the Jackrabbit people plan to add WebDAV as well... By the way I see no way why you should not program your management console to the Slide client API that translates your stuff to WebDAV. That one is nice, exists, is easy to program to *and* supports a standard. Oliver On Wed, 1 Dec 2004 10:27:38 -0500, Jeff Broberg <[EMAIL PROTECTED]> wrote: > Personally, I like the WebDav layer ontop of JSR170. I still feel that > Slide should expose jsr170 as one of its stores, so that it can have > relevance in the long term. I can understand using webdav to access the > content from the client, but to build out a web based management console > ontop of the repository, I do not want a proprietary api ( aka slides ), I > would prefer a standard. At that is where I see 170 being important. > > jeff > > > > -Original Message- > From: Carlos Villegas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 12:39 AM > To: Slide Users Mailing List > Subject: Re: Slide and JSR170 > > kranga wrote: > > I don't think jsr 170 forms a logical stack for Slide - who's primary > > concern is WebDAV protocol implementation. I am very skeptical of jsr > > 170 - more so after looking at participants - Fujitsu, IBM, BEA, Sun, > > HP, Borland aren't exactly companies I think of when considering > > content management systems. I think this is another example of the > > jcp's callous disregard for what already exists. Webdav, Delta V, ACL, > > WebDAV-search etc. already exist as standards in a language neutral > > way. Instead of specifying a java API that basically uses java native > > method calls in lieu of http, they've created a whole parallel spec set. > What a waste ... > > Well, I don't think we're talking about the same things here. Just because > there's SQL, it doesn't mean we don't need JDBC. They are two different > things, WebDAV is a protocol with an underlying model, as you say language > neutral. But to work with it from within a language like java we need an > API. Or else how do you communicate with a WebDAV server from Java. That's > why there's slide-webdavclient, or the slide internal server API. That > jsr170 parallels some of the concepts of WebDAV and related tools is only > natural but it's not a replacement, you can use jsr170 as the java webdav > client API or you can put WebDAV on top of a jsr170 repository server to > expose it remotely. I see it as the same difference as LDAP/JNDI or SQL/JDBC > or XML/SAX/DOM etc. > > Carlos > > - > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide and JSR170
I have been planning to experiment with it. Not sure when. If it turns out to be something worth while I'll gladly donate. Or at least I'll submit what I have as a starting point. -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 5:06 AM To: Slide Users Mailing List Subject: Re: Slide and JSR170 On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert <[EMAIL PROTECTED]> wrote: > - wrap a webdav api (e.g. slide) with the jsr170 api This has been discussed as in option inside Slide. If you plan to implement something like that would you consider donating it to Slide? Oliver - 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]
Re: Slide and JSR170
Great! Looking forward to that :) Oliver On Thu, 2 Dec 2004 10:21:25 -0500, John Gilbert <[EMAIL PROTECTED]> wrote: > I have been planning to experiment with it. Not sure when. If it turns > out to be something worth while I'll gladly donate. Or at least I'll > submit what I have as a starting point. > > > > > -Original Message- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 5:06 AM > To: Slide Users Mailing List > Subject: Re: Slide and JSR170 > > On Tue, 30 Nov 2004 23:13:45 -0500, John Gilbert <[EMAIL PROTECTED]> > wrote: > > - wrap a webdav api (e.g. slide) with the jsr170 api > > This has been discussed as in option inside Slide. If you plan to > implement something like that would you consider donating it to Slide? > > Oliver > > - > 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]
