You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/11/12 12:50:05 UTC
Re: Migrating to Avalon. Thoughts?
Just a note to let you know that there are a number of
threads currently running over on the dev@avalon.apache.org
concerning the establishment of a component repository
project. After reading your email I think that many of the
subjects you have addressed below are relevant to the things
the Avalon crew are currently debating.
Cheers, Steve.
Edison Too wrote:
>Hi,
>
>I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
>
>The server core can be broken down into 3 blocks
>1. Content repository (store?)
>2. User management
>3. Access Control management
>These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
>
>Advantage of migrating :
>1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
>2. Deployable as a standalone or servlet using Fortress or Phoenix.
>3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
>4. Attract more developers from the land of Avalon or Cocoon.
>I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
>
>I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
>
>I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
>
>Thoughts?
>
>Cheers,
>Edison Too
>
>On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>
>
>>[copying dev@cocoon because many people are in search for a serious versioned
>>content repository these days]
>>
>>Hello everyone,
>>
>>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>>and after having searched land and sea and having tried all possible
>>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>>use invest my effort in Slide, also because of the familiarity with the java
>>language compared to mod_dav which isn't really friendly for me]
>>
>>
>>
><snip/>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Slide optimisations
Posted by Nick Reddel <ni...@findesign.org>.
Hi
I´m developing a client application based on webdav, using Slide as the
server, which is accessing large collections (in the thousands), and I'm
running into problems with the time Slide takes to execute a PROPFIND on
large collections .
One thing I noticed in the PROPFIND method is that ~30% of the total
method time is taken in the call to <getLabeledResourceUri> in
<VersioningHelper>, since the helper class retrieves all the node
descriptors (including their properties) from the store - so in fact the
revisions are retrieved from the store 2 or 3 times rather than once.
Anyway, the following patch on <VersioningHelper> improves the response
time of PROPFIND by 20-30%. The assumption is that the URI of the latest
version of a resource is the URI itself, in all cases (I think this is
true, from the code, and it works).
* $Header:
/home/cvspublic/jakarta-slide/src/webdav/server/org/apache/slide/webdav/
util/VersioningHelper.java,v 1.91 2003/10/16 10:51:24 pnever Exp $
* $Revision: 1.91 $
Original (lines 1933-1935)
public static String getLabeledResourceUri(NamespaceAccessToken
nsaToken, SlideToken sToken, Content content, String resourcePath,
String label) throws SlideException, LabeledRevisionNotFoundException {
NodeRevisionDescriptors revisionDescriptors =
content.retrieve( sToken, resourcePath );
Patched (1933-1938)
public static String getLabeledResourceUri(NamespaceAccessToken
nsaToken, SlideToken sToken, Content content, String resourcePath,
String label) throws SlideException, LabeledRevisionNotFoundException {
if (label == null){
return resourcePath;
}
NodeRevisionDescriptors revisionDescriptors =
content.retrieve( sToken, resourcePath );
Questions: is it worthwhile caring about optimisation yet, and is this
the proper forum for such a small patch, or should I address a Slide
developer directly?
Nick Reddel
mailto:nick@ella-associates.com
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.