You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Daniel Florey <df...@apache.org> on 2004/08/03 10:30:39 UTC
Slide 3.0 long term plans
Hi folks,
I've started a thread for discussions about architectural changes in
Slide 3.0 some time ago. What about moving this to the Wiki to have a
centralized point for further discussions?
Beside this I've thought about the following:
As Slide 3.0 will introduce some major changes that will lead to Slide
level api incompatibilites, I'd vote for setting up a new CVS module for
Slide 3.0 as tomcat is doing the same for major versions. This would
give us the chance to set up a clean directory structure that reflects
our increased wisdom.
As the Slide subprojects are big ones (server,clientlib,
commandlineclient, testsuite, projector,...) it might also be a choice
to split them into different cvs modules. What do you think about this?
This would lead to the question if we should try to shift Slide to
apache top level (webdav.apache.org) to give the users a better
understanding what Slide is all about and to simplify the access to the
different subprojects. Remind that the testsuite, the client or
projector are not tied to Slide, they work with every WebDAV-compliant
server.
As stated in the subject of this mail, this are long term plans. But we
should start to think about the way to go now as there is a lot of
administrative work to be done to achieve this.
Cheers,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Daniel Florey <df...@apache.org>.
Gianugo Rabellino schrieb:
>>As Slide 3.0 will introduce some major changes that will lead to Slide
>>level api incompatibilites, I'd vote for setting up a new CVS module for
>> Slide 3.0 as tomcat is doing the same for major versions. This would
>>give us the chance to set up a clean directory structure that reflects
>>our increased wisdom.
>>As the Slide subprojects are big ones (server,clientlib,
>>commandlineclient, testsuite, projector,...) it might also be a choice
>>to split them into different cvs modules. What do you think about this?
>>This would lead to the question if we should try to shift Slide to
>>apache top level (webdav.apache.org) to give the users a better
>>understanding what Slide is all about and to simplify the access to the
>>different subprojects.
>>
>>
>
>I know I don't quite belong here, but just wanted to throw my .2 cents
>with a couple of thoughts:
>
>1. I'd be glad to see Slide grow as a TLP, but wouldn't webdav.apache.org
>be somehow limiting, given that Slide isn't just a webdav server (JCRRI
>being the first and foremost feature beyond webdav)? Also, it might clash
>with mod_dav somehow...
>
>
Slide is more than just the server, it contains different subprojects
dedicated to WebDAV. So I'd still the idea of having a TLP called webdav...
>2. Isn't it a good time for webdav folks to move to Subversion? :-) You
>have no idea on how it made my life easier: apart from being generally
>better, faster and nicer, as a roadwarrior, I have to painfully grab CVS
>snapshot whenever I get to an open Internet access. When I'm behind a
>nasty firewall, and it happens quite frequently, I'm relieved to know that
>I can always access the latest versions of the sources via plain HTTP.
>
>
Yes, good idea as subversion is also using WebDAV/DeltaV as it's
protocol :-)
>Ciao,
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Gianugo Rabellino <gi...@apache.org>.
> As Slide 3.0 will introduce some major changes that will lead to Slide
> level api incompatibilites, I'd vote for setting up a new CVS module for
> Slide 3.0 as tomcat is doing the same for major versions. This would
> give us the chance to set up a clean directory structure that reflects
> our increased wisdom.
> As the Slide subprojects are big ones (server,clientlib,
> commandlineclient, testsuite, projector,...) it might also be a choice
> to split them into different cvs modules. What do you think about this?
> This would lead to the question if we should try to shift Slide to
> apache top level (webdav.apache.org) to give the users a better
> understanding what Slide is all about and to simplify the access to the
> different subprojects.
I know I don't quite belong here, but just wanted to throw my .2 cents
with a couple of thoughts:
1. I'd be glad to see Slide grow as a TLP, but wouldn't webdav.apache.org
be somehow limiting, given that Slide isn't just a webdav server (JCRRI
being the first and foremost feature beyond webdav)? Also, it might clash
with mod_dav somehow...
2. Isn't it a good time for webdav folks to move to Subversion? :-) You
have no idea on how it made my life easier: apart from being generally
better, faster and nicer, as a roadwarrior, I have to painfully grab CVS
snapshot whenever I get to an open Internet access. When I'm behind a
nasty firewall, and it happens quite frequently, I'm relieved to know that
I can always access the latest versions of the sources via plain HTTP.
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Daniel Florey <df...@apache.org>.
We could take the following steps to bring things to light:
- Finishing the JSR-170 RI (including versioning, searching...)
There should be people around who are willing to help if they know that
the Slide project hosts the ri.
- Cleaning up the WebDAV layer
Currently the Slide webdav-layer is containing not only the request
parsing and response generation, but also some webdav specific logic.
The WebDAV can be cleaned and speeded up by separating the marshalling
from the logic. I started to design some interfaces that represent the
webdav-methods on java level.
By implementing these interfaces we could generate a layer of
abstraction that will make it much easier to map webdav-calls to the
jcrri. This would be a hard task with the current code.
These two steps can be done simultaneous.
When these steps are done we can check out how to build the full
webdav-layer of top of jcrri. If this task fails, no work is lost as we
can use both the jcrri and the cleaned up Slide code in future.
Another approach would be to use the jcrri as a Slide store, but this
would lead into trouble as we get inconsitencies when accessing the data
via both webDAV and jcr-170 api.
So I'd vote for the first approach.
Cheers,
Daniel
>We definitely need to start walking through features point by point to map
>JCR and webDAV, but, as a high level comment, I think most of the mismatch
>is manageable. For example, JCR takes a broad view of authorization and it
>would be possible to creat a JCR implementation with, for example,
>policy-based access controls. It's also possible to do access control lists
>that map well with webdav.
>
>So - it should not be hard to make a webdav-centric JCR by design, (or
>perhaps keep a general design and make webdav compatibility a configuration
>option). It could be hard to provide webdav on top of *any* JCR but that's
>not really Slide's issue.
>
>(Similar issues exists elsewhere - JCR allows multivalued properties which
>webdav doesn't support, but you can limit the JCR content model to disallow
>multivalued properties (or define your mapping through webdav)).
>
>There could still be gotcha's, but in general JCR has followed the model of
>exposing server-managed information through properties much like webdav and
>a JCRclient-webdav-JCRserver model has certainly been implicit the thinking.
>If there are specific issues that can be identified quickly, I don't think
>JCR is quite final (through public review but not yet at a draft final
>spec) - there may still be ways to fix things.
>
> Jim
>
>
>
>----- Original Message -----
>From: "Daniel Florey" <df...@apache.org>
>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>Sent: Tuesday, August 03, 2004 8:20 AM
>Subject: Re: Slide 3.0 long term plans
>
>
>
>
>>Stefan Guggisberg schrieb:
>>
>>
>>
>>>Daniel Florey wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Yes, I've seen this and it looks very promising. But as far as I can
>>>>tell, it will be much more complicated to build the deltaV, acl,
>>>>transaction, notification and dasl specs on top of jsr-170.
>>>>
>>>>
>>>>
>>>>
>>>it's certainly not trivial but i don't see why it shouldn't be possible.
>>>all required building blocks are there in JSR 170: versioning (closely
>>>sync'ed with JSR 147), observation, JTA support, observation, search...
>>>
>>>
>>>
>>>
>>>
>>To find out if it is possible to build the complete webdav layer on top
>>of jsr-170 is to give it a try. I don't know much about jsr-170, but I
>>didn't find the following webdav-features in jsr-170:
>>Locking:
>>- timeout of locks
>>Acl:
>>- handling of principals
>>- aggregation of actions (permissions in jsr terms)
>>deltaV:
>>- Baselines, Activities...
>>
>>
>>
>>>>I see. But IMO it is a key feature of the 3.0 release to have a single
>>>>API that can be used on client and server side (see 3.0 design approach
>>>>in the wiki). So how can we achieve this when using JSR 170? Just
>>>>
>>>>
>curious.
>
>
>>>>
>>>>
>>>my idea would be to expose the JCR api on the server and on the client.
>>>i've implemented a transparent RMI layer for the JCR api for a previous
>>>version of the ri. the client side JCR implementation could of course use
>>>any transport protocol, that's up to the implementation.
>>>
>>>
>>>
>>>
>>I think this is a fundamental different approach.
>>Currently the Slide project is WebDAV-centric. There is a mature
>>testsuite that runs with different webdav-servers, a webdav commandline
>>client etc.
>>The goal is to have a first class WebDAV-server that supports as many
>>aspects of the WebDAV protocol as possible. If we can achieve a broader
>>WebDAV-support, we can use the growing number of nice WebDAV-clients
>>around. If subversion is getting more WebDAV-compliant and we are
>>implementing more of the deltaV features, we can even use the fine
>>subversion clients.
>>A lot of people are using Slide to make their content repository
>>WebDAV-enabled. So the bridge from Slide to legacy repositories should
>>be simplified.
>>IMO jsr-170 should become the default repository/store if it supports
>>all the WebDAV features.
>>So, to find out how to proceed, we need an expert who knows all about
>>WebDAV *and* the jsr-170 spec...
>>
>>Cheers,
>>Daniel
>>
>>
>>
>>>WebDAV could IMO be used as an alternative for accessing the
>>>resource-centric
>>>content in the repository.
>>>
>>>regards
>>>stefan
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Jim Myers <ji...@verizon.net>.
We definitely need to start walking through features point by point to map
JCR and webDAV, but, as a high level comment, I think most of the mismatch
is manageable. For example, JCR takes a broad view of authorization and it
would be possible to creat a JCR implementation with, for example,
policy-based access controls. It's also possible to do access control lists
that map well with webdav.
So - it should not be hard to make a webdav-centric JCR by design, (or
perhaps keep a general design and make webdav compatibility a configuration
option). It could be hard to provide webdav on top of *any* JCR but that's
not really Slide's issue.
(Similar issues exists elsewhere - JCR allows multivalued properties which
webdav doesn't support, but you can limit the JCR content model to disallow
multivalued properties (or define your mapping through webdav)).
There could still be gotcha's, but in general JCR has followed the model of
exposing server-managed information through properties much like webdav and
a JCRclient-webdav-JCRserver model has certainly been implicit the thinking.
If there are specific issues that can be identified quickly, I don't think
JCR is quite final (through public review but not yet at a draft final
spec) - there may still be ways to fix things.
Jim
----- Original Message -----
From: "Daniel Florey" <df...@apache.org>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
Sent: Tuesday, August 03, 2004 8:20 AM
Subject: Re: Slide 3.0 long term plans
> Stefan Guggisberg schrieb:
>
> >Daniel Florey wrote:
> >
> >
> >
> >>Yes, I've seen this and it looks very promising. But as far as I can
> >>tell, it will be much more complicated to build the deltaV, acl,
> >>transaction, notification and dasl specs on top of jsr-170.
> >>
> >>
> >
> >it's certainly not trivial but i don't see why it shouldn't be possible.
> >all required building blocks are there in JSR 170: versioning (closely
> >sync'ed with JSR 147), observation, JTA support, observation, search...
> >
> >
> >
> To find out if it is possible to build the complete webdav layer on top
> of jsr-170 is to give it a try. I don't know much about jsr-170, but I
> didn't find the following webdav-features in jsr-170:
> Locking:
> - timeout of locks
> Acl:
> - handling of principals
> - aggregation of actions (permissions in jsr terms)
> deltaV:
> - Baselines, Activities...
>
> >>I see. But IMO it is a key feature of the 3.0 release to have a single
> >>API that can be used on client and server side (see 3.0 design approach
> >>in the wiki). So how can we achieve this when using JSR 170? Just
curious.
> >>
> >>
> >
> >my idea would be to expose the JCR api on the server and on the client.
> >i've implemented a transparent RMI layer for the JCR api for a previous
> >version of the ri. the client side JCR implementation could of course use
> >any transport protocol, that's up to the implementation.
> >
> >
> I think this is a fundamental different approach.
> Currently the Slide project is WebDAV-centric. There is a mature
> testsuite that runs with different webdav-servers, a webdav commandline
> client etc.
> The goal is to have a first class WebDAV-server that supports as many
> aspects of the WebDAV protocol as possible. If we can achieve a broader
> WebDAV-support, we can use the growing number of nice WebDAV-clients
> around. If subversion is getting more WebDAV-compliant and we are
> implementing more of the deltaV features, we can even use the fine
> subversion clients.
> A lot of people are using Slide to make their content repository
> WebDAV-enabled. So the bridge from Slide to legacy repositories should
> be simplified.
> IMO jsr-170 should become the default repository/store if it supports
> all the WebDAV features.
> So, to find out how to proceed, we need an expert who knows all about
> WebDAV *and* the jsr-170 spec...
>
> Cheers,
> Daniel
>
> >WebDAV could IMO be used as an alternative for accessing the
> >resource-centric
> >content in the repository.
> >
> >regards
> >stefan
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Daniel Florey <df...@apache.org>.
Stefan Guggisberg schrieb:
>Daniel Florey wrote:
>
>
>
>>Yes, I've seen this and it looks very promising. But as far as I can
>>tell, it will be much more complicated to build the deltaV, acl,
>>transaction, notification and dasl specs on top of jsr-170.
>>
>>
>
>it's certainly not trivial but i don't see why it shouldn't be possible.
>all required building blocks are there in JSR 170: versioning (closely
>sync'ed with JSR 147), observation, JTA support, observation, search...
>
>
>
To find out if it is possible to build the complete webdav layer on top
of jsr-170 is to give it a try. I don't know much about jsr-170, but I
didn't find the following webdav-features in jsr-170:
Locking:
- timeout of locks
Acl:
- handling of principals
- aggregation of actions (permissions in jsr terms)
deltaV:
- Baselines, Activities...
>>I see. But IMO it is a key feature of the 3.0 release to have a single
>>API that can be used on client and server side (see 3.0 design approach
>>in the wiki). So how can we achieve this when using JSR 170? Just curious.
>>
>>
>
>my idea would be to expose the JCR api on the server and on the client.
>i've implemented a transparent RMI layer for the JCR api for a previous
>version of the ri. the client side JCR implementation could of course use
>any transport protocol, that's up to the implementation.
>
>
I think this is a fundamental different approach.
Currently the Slide project is WebDAV-centric. There is a mature
testsuite that runs with different webdav-servers, a webdav commandline
client etc.
The goal is to have a first class WebDAV-server that supports as many
aspects of the WebDAV protocol as possible. If we can achieve a broader
WebDAV-support, we can use the growing number of nice WebDAV-clients
around. If subversion is getting more WebDAV-compliant and we are
implementing more of the deltaV features, we can even use the fine
subversion clients.
A lot of people are using Slide to make their content repository
WebDAV-enabled. So the bridge from Slide to legacy repositories should
be simplified.
IMO jsr-170 should become the default repository/store if it supports
all the WebDAV features.
So, to find out how to proceed, we need an expert who knows all about
WebDAV *and* the jsr-170 spec...
Cheers,
Daniel
>WebDAV could IMO be used as an alternative for accessing the
>resource-centric
>content in the repository.
>
>regards
>stefan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: Slide 3.0 long term plans
Posted by laurent belmonte <la...@aliacom.fr>.
On Tue, 2004-08-03 at 14:44 +0200, Stefan Guggisberg wrote:
> Daniel Florey wrote:
>
> > Yes, I've seen this and it looks very promising. But as far as I can
> > tell, it will be much more complicated to build the deltaV, acl,
> > transaction, notification and dasl specs on top of jsr-170.
>
> it's certainly not trivial but i don't see why it shouldn't be possible.
> all required building blocks are there in JSR 170: versioning (closely
> sync'ed with JSR 147), observation, JTA support, observation, search...
>
acl ?
> > I see. But IMO it is a key feature of the 3.0 release to have a single
> > API that can be used on client and server side (see 3.0 design approach
> > in the wiki). So how can we achieve this when using JSR 170? Just curious.
>
> my idea would be to expose the JCR api on the server and on the client.
> i've implemented a transparent RMI layer for the JCR api for a previous
> version of the ri. the client side JCR implementation could of course use
> any transport protocol, that's up to the implementation.
>
> WebDAV could IMO be used as an alternative for accessing the
> resource-centric
> content in the repository.
>
> regards
> stefan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: Slide 3.0 long term plans
Posted by Stefan Guggisberg <st...@apache.org>.
Daniel Florey wrote:
> Yes, I've seen this and it looks very promising. But as far as I can
> tell, it will be much more complicated to build the deltaV, acl,
> transaction, notification and dasl specs on top of jsr-170.
it's certainly not trivial but i don't see why it shouldn't be possible.
all required building blocks are there in JSR 170: versioning (closely
sync'ed with JSR 147), observation, JTA support, observation, search...
> I see. But IMO it is a key feature of the 3.0 release to have a single
> API that can be used on client and server side (see 3.0 design approach
> in the wiki). So how can we achieve this when using JSR 170? Just curious.
my idea would be to expose the JCR api on the server and on the client.
i've implemented a transparent RMI layer for the JCR api for a previous
version of the ri. the client side JCR implementation could of course use
any transport protocol, that's up to the implementation.
WebDAV could IMO be used as an alternative for accessing the
resource-centric
content in the repository.
regards
stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Daniel Florey <df...@apache.org>.
Stefan Guggisberg schrieb:
>Daniel Florey wrote:
>
>
>
>>This would be great if jcrri would provide all requirements to build a
>>WebDAV layer on top of it (including all the current drafts). As see
>>slide as a bunch of java software related to WebDAV. If we could achieve
>>this using jcrri I'd vote for it. Stefan (currently working on the
>>jcrri) stated in his mails that there might be some problems regarding
>>the content model.
>>
>>
>
>sorry daniel, you got me wrong. i was saying that building the WebDAV layer
>on top of the JCR api is relatively straight forward. in fact, we already
>did a quick&dirty implementation that is running on top of the jcrri.
>connect your WebDAV client to http://jsr170tools.day.com/crx/repository
>and give it a try.
>
>
Yes, I've seen this and it looks very promising. But as far as I can
tell, it will be much more complicated to build the deltaV, acl,
transaction, notification and dasl specs on top of jsr-170.
>implementing the JCR api on top of the WebDAV client lib or the Slide api
>on the other hand would be quite difficult because of the different content
>models of JSR 170 and Slide/WebDAV; WebDAV/Slide's model is resource centric
>whereas JSR 170's model is fine granular, i.e. it supports unstructured,
>semi-structured and well-structured content.
>
>you can model WebDAV content very easily in JSR 170 but you can't model
>all different kinds of JSR 170 content in WebDAV.
>
>
I see. But IMO it is a key feature of the 3.0 release to have a single
API that can be used on client and server side (see 3.0 design approach
in the wiki). So how can we achieve this when using JSR 170? Just curious.
Daniel
>regards
>stefan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: Slide 3.0 long term plans
Posted by Stefan Guggisberg <st...@apache.org>.
Daniel Florey wrote:
> This would be great if jcrri would provide all requirements to build a
> WebDAV layer on top of it (including all the current drafts). As see
> slide as a bunch of java software related to WebDAV. If we could achieve
> this using jcrri I'd vote for it. Stefan (currently working on the
> jcrri) stated in his mails that there might be some problems regarding
> the content model.
sorry daniel, you got me wrong. i was saying that building the WebDAV layer
on top of the JCR api is relatively straight forward. in fact, we already
did a quick&dirty implementation that is running on top of the jcrri.
connect your WebDAV client to http://jsr170tools.day.com/crx/repository
and give it a try.
implementing the JCR api on top of the WebDAV client lib or the Slide api
on the other hand would be quite difficult because of the different content
models of JSR 170 and Slide/WebDAV; WebDAV/Slide's model is resource centric
whereas JSR 170's model is fine granular, i.e. it supports unstructured,
semi-structured and well-structured content.
you can model WebDAV content very easily in JSR 170 but you can't model
all different kinds of JSR 170 content in WebDAV.
regards
stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Daniel Florey <df...@apache.org>.
Unico Hommes schrieb:
> Daniel Florey wrote:
>
>> Hi folks,
>> I've started a thread for discussions about architectural changes in
>> Slide 3.0 some time ago. What about moving this to the Wiki to have a
>> centralized point for further discussions?
>>
>> Beside this I've thought about the following:
>> As Slide 3.0 will introduce some major changes that will lead to
>> Slide level api incompatibilites, I'd vote for setting up a new CVS
>> module for Slide 3.0 as tomcat is doing the same for major versions.
>> This would give us the chance to set up a clean directory structure
>> that reflects our increased wisdom.
>> As the Slide subprojects are big ones (server,clientlib,
>> commandlineclient, testsuite, projector,...) it might also be a
>> choice to split them into different cvs modules. What do you think
>> about this?
>> This would lead to the question if we should try to shift Slide to
>> apache top level (webdav.apache.org) to give the users a better
>> understanding what Slide is all about and to simplify the access to
>> the different subprojects. Remind that the testsuite, the client or
>> projector are not tied to Slide, they work with every
>> WebDAV-compliant server.
>> As stated in the subject of this mail, this are long term plans. But
>> we should start to think about the way to go now as there is a lot of
>> administrative work to be done to achieve this.
>>
>
> Personally, I would love to see a webdav TLP. As you note there is
> enough stuff in Slide to account for it. Regardless of whether or not
> we decide to push for a TLP I think it would be good to move to
> subversion. Many Apache projects already did the migration.
>
> Regarding the evolution of the Slide webdav server, I think we should
> adopt jcrri to build version 3.0 on. This will also attract a lot of
> different people to the project and thus be a great community builder.
This would be great if jcrri would provide all requirements to build a
WebDAV layer on top of it (including all the current drafts). As see
slide as a bunch of java software related to WebDAV. If we could achieve
this using jcrri I'd vote for it. Stefan (currently working on the
jcrri) stated in his mails that there might be some problems regarding
the content model.
We have to investigate, which api will match best (jsr-147 or jsr-170 or
something totally different...)
Daniel
>
> --
> Unico
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Slide 3.0 long term plans
Posted by Unico Hommes <un...@hippo.nl>.
Daniel Florey wrote:
> Hi folks,
> I've started a thread for discussions about architectural changes in
> Slide 3.0 some time ago. What about moving this to the Wiki to have a
> centralized point for further discussions?
>
> Beside this I've thought about the following:
> As Slide 3.0 will introduce some major changes that will lead to Slide
> level api incompatibilites, I'd vote for setting up a new CVS module
> for Slide 3.0 as tomcat is doing the same for major versions. This
> would give us the chance to set up a clean directory structure that
> reflects our increased wisdom.
> As the Slide subprojects are big ones (server,clientlib,
> commandlineclient, testsuite, projector,...) it might also be a choice
> to split them into different cvs modules. What do you think about this?
> This would lead to the question if we should try to shift Slide to
> apache top level (webdav.apache.org) to give the users a better
> understanding what Slide is all about and to simplify the access to
> the different subprojects. Remind that the testsuite, the client or
> projector are not tied to Slide, they work with every WebDAV-compliant
> server.
> As stated in the subject of this mail, this are long term plans. But
> we should start to think about the way to go now as there is a lot of
> administrative work to be done to achieve this.
>
Personally, I would love to see a webdav TLP. As you note there is
enough stuff in Slide to account for it. Regardless of whether or not we
decide to push for a TLP I think it would be good to move to subversion.
Many Apache projects already did the migration.
Regarding the evolution of the Slide webdav server, I think we should
adopt jcrri to build version 3.0 on. This will also attract a lot of
different people to the project and thus be a great community builder.
--
Unico
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: Slide 3.0 long term plans
Posted by Michael Oliver <ol...@sourceonenet.com>.
Although not a formal voter this gets my +1
Michael Oliver
CTO
Alarius Systems LLC
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
*Note new email changed from oliverm@matrix-media.com
-----Original Message-----
From: Daniel Florey [mailto:dflorey@apache.org]
Sent: Tuesday, August 03, 2004 1:31 AM
To: Slide Developers Mailing List
Subject: Slide 3.0 long term plans
Hi folks,
I've started a thread for discussions about architectural changes in
Slide 3.0 some time ago. What about moving this to the Wiki to have a
centralized point for further discussions?
Beside this I've thought about the following:
As Slide 3.0 will introduce some major changes that will lead to Slide
level api incompatibilites, I'd vote for setting up a new CVS module for
Slide 3.0 as tomcat is doing the same for major versions. This would
give us the chance to set up a clean directory structure that reflects
our increased wisdom.
As the Slide subprojects are big ones (server,clientlib,
commandlineclient, testsuite, projector,...) it might also be a choice
to split them into different cvs modules. What do you think about this?
This would lead to the question if we should try to shift Slide to
apache top level (webdav.apache.org) to give the users a better
understanding what Slide is all about and to simplify the access to the
different subprojects. Remind that the testsuite, the client or
projector are not tied to Slide, they work with every WebDAV-compliant
server.
As stated in the subject of this mail, this are long term plans. But we
should start to think about the way to go now as there is a lot of
administrative work to be done to achieve this.
Cheers,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org