You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/04/12 14:38:17 UTC
Commentary (was Re: [Analysis] Cocoon, The Play)
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>>Coming to a theater near you, Cocoon 2.1: Same Plot, Different Story!
>
>
> Oh, I love it, love it, love it. :)
>
> Now, let's get nasty! how about XSLT-transforming the sitemap into Jon
> Bosak Play DTD :)
I'm not familiar with Jon Bosak :(
>
> A sidenote: I'm pretty sure that everybody was laughing so loud that all
> your points about refactorization was not really taken seriouly.
Probably, but it was an example of analyzing Cocoon with the "Play"
analogy that I was introduced to in Avalon.
>
> But I think Berin touches a few serious design issues
> (overcomponentization, role of cache control, component isolation) that
> we must seriously consider.
Those are the biggest beefs I have with Cocoon right now. In my view of
the world, the existences of a Cache should be invisible to the anybody
who is not specifically tuning it. We should notice its existence
solely by the virtue of our page loads being faster.
The Overcomponentization is a big problem. Unless we start keeping an
eye on it now, we will *never* get around to fixing it.
>
> I only think that if we do this for 2.1 it will take forever for us to
> reach a final release... this is the reason why I was considering
> componentization refactoring to happen for 2.2 at least.
>
> What do you think?
>
I'm not saying we should go through and implement the COcoon
Application COmponentarchitecture now. I am saying we need to quell any
further unnecessary componentization as we are now busting at the seams.
What I would like to see is that all _optional_ components be broken out
into little "mini" projects with their associated classes all in one
place. Kind of like what we recently did with Excalibur. In fact, when
we finally get the bugs worked out of the dependancy system, I'm sure
you can adopt the recursive dependancy build system in Excalibur for the
Cocoon components.
That way, the _only_ thing in the cocoon.jar is the core essential
Cocoon components. All things optional are in separate jars so that we
can create an install that is minimalist.
Another thing that it allows us to do is start considering the role of
the sitemap in regards to dynamic loading of jars. We currently let the
servlet engine load all jars associated with a webapp. If we want true
pluggability, we need to let subsitemaps load their own set of jars so
that we can have true component isolation. Also, so that when we come
up with the formal Cocoon Application ComponenT Infrastructure (CACTI?)
or whatever we call it, we also have the component loading
infrastructure in place.
I don't think that is unreasonable. It is a good first step toward the
componentization process, allowing us to attack one aspect of it and
provide some real feedback before we add in the application component
infrastructure.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by giacomo <gi...@apache.org>.
On Tue, 16 Apr 2002, Berin Loritsch wrote:
> Vadim Gritsenko wrote:
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > ...
> >
> >>You have simple sitemaps for simple problems and complex sitemaps for
> >>complex problems.
> >>
> >>Remember, we have a wide range of needs. One sitemap is not going to
> >>fit all needs.
> >>
> >
> > ...
> >
> > Ok. Will this be an option (pluggable/configurable) or an optimization
> > of the sitemap engine? In both cases, I don't mind if it does not breaks
> > sitemap and provides speed up for some people out there.
>
>
> This would be a *possibility* as a foundation for a new Sitemap syntax.
> In the end, when we start compiling COcoon Blocks, we will have a highly
> specialized sitemap that will allow us to perform all types of
> optimizations that would otherwise be impossible with the current
> general purpose sitemap.
>
> Keep in mind, we have *several* components for Generators, Transformers,
> Serializers, etc. We really only have one implementation for the
> sitemap. I am advocating formalizing the contract of the Sitemap
> (or Processor since that is what its interface is), so that we have
> the possibility of comming up with a truly fast sitemap that is
> specialized for our purposes.
I too see a more decalrative sitemap syntax possible now that we can
move all the procedural (Actions and some Selectors) stuff into the
flowmap.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> ...
>
>>You have simple sitemaps for simple problems and complex sitemaps for
>>complex problems.
>>
>>Remember, we have a wide range of needs. One sitemap is not going to
>>fit all needs.
>>
>
> ...
>
> Ok. Will this be an option (pluggable/configurable) or an optimization
> of the sitemap engine? In both cases, I don't mind if it does not breaks
> sitemap and provides speed up for some people out there.
This would be a *possibility* as a foundation for a new Sitemap syntax.
In the end, when we start compiling COcoon Blocks, we will have a highly
specialized sitemap that will allow us to perform all types of
optimizations that would otherwise be impossible with the current
general purpose sitemap.
Keep in mind, we have *several* components for Generators, Transformers,
Serializers, etc. We really only have one implementation for the
sitemap. I am advocating formalizing the contract of the Sitemap
(or Processor since that is what its interface is), so that we have
the possibility of comming up with a truly fast sitemap that is
specialized for our purposes.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
...
>
> You have simple sitemaps for simple problems and complex sitemaps for
> complex problems.
>
> Remember, we have a wide range of needs. One sitemap is not going to
> fit all needs.
>
...
Ok. Will this be an option (pluggable/configurable) or an optimization
of the sitemap engine? In both cases, I don't mind if it does not breaks
sitemap and provides speed up for some people out there.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Stefano Mazzocchi wrote:
>>
>>>Berin Loritsch wrote:
>>>
>>>
>>>>Berin Loritsch wrote:
>>>>
>>>>
>>>>We need a Sitemap that has a decision time that is fairly
>>>>constant--as opposed to the length depending on the position
>>>>in the sitemap.
>>>
>>>
>>>Yes, you are right, we need a way to address this, but I really
>>
> can't
>
>>>find one.
>>>
>>>I mean: having wildcarded hashmaps is something that I wouldn't know
>>
> how
>
>>>to algorithmically design.
>>>
>>>Any idea?
>>
>>
>>It stems from having your decisions based strictly by one aspect in a
>>particular Sitemap. The most natural aspect being URI.
>>
>>Because the most common URI mapping is to *local* resources, we can
>>unroll them.
>>
>>However, you are right--there is no clean way of algorithmically
>>addressing wildcard hashmaps.
>>
>>The key problem is in the Hashcode generation. It is guaranteed that
>>"docs/pub(*)/*.html" will not have the same hashcode as
>>"docs/pub(5324)/index.html".
>>
>>However, by breaking the URI up, we can approach it by narrowing
>>down our matching. I.e. We apply the concept of least common
>>denominator (remember fractions?). We would break the URI based on
>>where the first wildcard approaches:
>>
>>docs/pub(*)/*.html
>>images/*.jpg
>>
>>The LCD is the seventh character. We can do a hash on URIs with the
>>first seven characters, and then iterate through the remaining
>>URIs. THe HashMap would have the following structure:
>>
>>
>>{
>> {Match("docs/pu", "docs/pub(*)/*.html"), Pipeline},
>> {Match("images/", "images/*.jpg"), Pipeline}
>>}
>>
>>The "Match" object exposes the LCD's HashCode, and uses the
>>full string for the .equals() operation.
>
>
> This could work for simple pipelines a-la:
>
> <map:pipeline>
> <map:match/>
> ...
> <map:match/>
> </map:pipeline>
>
> How about a bit more complex situation:
You have simple sitemaps for simple problems and complex sitemaps for
complex problems.
Remember, we have a wide range of needs. One sitemap is not going to
fit all needs.
The optimization I am speaking toward is strictly a declarative approach
to a pipeline. IF the individual pipeline is not a simple
Generator->Transformer->Serializer
pipeline, nad has a level of dynamic resolution of portions of the
pipeline, we have resolved the core part already.
The dynamic pipeline (i.e. selecting transformers based on criteria)
is simple enough to delay that logic into that level.
>
> <map:pipeline>
> ...
> <map:match>
> <map:generate/>
> <map:match>
> <map:transform/>
> </map:match>
> <map:match>
> <map:transform/>
> </map:match>
> <map:serialize/>
> <map:match>
> ...
> </map:pipeline>
>
> And how do you address full sitemap syntax, including selectors/non-URI
> matchers/actions/issues? Or it will be not addressed by such
> optimization?
>
> Vadim
>
> <snip what="Match sketch code"/>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Stefano Mazzocchi wrote:
> > Berin Loritsch wrote:
> >
> >>Berin Loritsch wrote:
> >>
> >>
> >>We need a Sitemap that has a decision time that is fairly
> >>constant--as opposed to the length depending on the position
> >>in the sitemap.
> >
> >
> > Yes, you are right, we need a way to address this, but I really
can't
> > find one.
> >
> > I mean: having wildcarded hashmaps is something that I wouldn't know
how
> > to algorithmically design.
> >
> > Any idea?
>
>
> It stems from having your decisions based strictly by one aspect in a
> particular Sitemap. The most natural aspect being URI.
>
> Because the most common URI mapping is to *local* resources, we can
> unroll them.
>
> However, you are right--there is no clean way of algorithmically
> addressing wildcard hashmaps.
>
> The key problem is in the Hashcode generation. It is guaranteed that
> "docs/pub(*)/*.html" will not have the same hashcode as
> "docs/pub(5324)/index.html".
>
> However, by breaking the URI up, we can approach it by narrowing
> down our matching. I.e. We apply the concept of least common
> denominator (remember fractions?). We would break the URI based on
> where the first wildcard approaches:
>
> docs/pub(*)/*.html
> images/*.jpg
>
> The LCD is the seventh character. We can do a hash on URIs with the
> first seven characters, and then iterate through the remaining
> URIs. THe HashMap would have the following structure:
>
>
> {
> {Match("docs/pu", "docs/pub(*)/*.html"), Pipeline},
> {Match("images/", "images/*.jpg"), Pipeline}
> }
>
> The "Match" object exposes the LCD's HashCode, and uses the
> full string for the .equals() operation.
This could work for simple pipelines a-la:
<map:pipeline>
<map:match/>
...
<map:match/>
</map:pipeline>
How about a bit more complex situation:
<map:pipeline>
...
<map:match>
<map:generate/>
<map:match>
<map:transform/>
</map:match>
<map:match>
<map:transform/>
</map:match>
<map:serialize/>
<map:match>
...
</map:pipeline>
And how do you address full sitemap syntax, including selectors/non-URI
matchers/actions/issues? Or it will be not addressed by such
optimization?
Vadim
<snip what="Match sketch code"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>>Berin Loritsch wrote:
>>
>>
>>We need a Sitemap that has a decision time that is fairly
>>constant--as opposed to the length depending on the position
>>in the sitemap.
>
>
> Yes, you are right, we need a way to address this, but I really can't
> find one.
>
> I mean: having wildcarded hashmaps is something that I wouldn't know how
> to algorithmically design.
>
> Any idea?
It stems from having your decisions based strictly by one aspect in a
particular Sitemap. The most natural aspect being URI.
Because the most common URI mapping is to *local* resources, we can
unroll them.
However, you are right--there is no clean way of algorithmically
addressing wildcard hashmaps.
The key problem is in the Hashcode generation. It is guaranteed that
"docs/pub(*)/*.html" will not have the same hashcode as
"docs/pub(5324)/index.html".
However, by breaking the URI up, we can approach it by narrowing
down our matching. I.e. We apply the concept of least common
denominator (remember fractions?). We would break the URI based on
where the first wildcard approaches:
docs/pub(*)/*.html
images/*.jpg
The LCD is the seventh character. We can do a hash on URIs with the
first seven characters, and then iterate through the remaining
URIs. THe HashMap would have the following structure:
{
{Match("docs/pu", "docs/pub(*)/*.html"), Pipeline},
{Match("images/", "images/*.jpg"), Pipeline}
}
The "Match" object exposes the LCD's HashCode, and uses the
full string for the .equals() operation.
I.e.:
Match
{
private String m_lcd;
private String m_uri;
public Match(int lcdChars, String uri)
{
m_lcd = uri.Left(lcdChars);
m_uri = uri;
}
public long hashcode()
{
m_lcd.hashcode();
}
public bool equals(Object other)
{
return 0 == compareTo(other);
}
public int compareTo(Object other)
{
// perform matching logic:
return m_uri.compareTo(other);
}
}
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> Berin Loritsch wrote:
> > Stefano Mazzocchi wrote:
> >>
> >> But I think Berin touches a few serious design issues
> >> (overcomponentization, role of cache control, component isolation) that
> >> we must seriously consider.
> >
>
> I think you also missed one of the points. That is the current
> implementation of the Sitemap *pretends* to declarative when in
> fact it is truly procedural in the implementation.
>
> I think we should choose an approach for each type of Sitemap.
> Using my definition of Sitemap, we can have the current sitemap,
> the flowmap, or a proprietary map (nice place for a compiled
> Cocoon Block, eh?).
>
> I'm not saying it needs to be done for Cocoon 2.1, but soon.
> We should have a declarative sitemap, and a procedural one.
>
> One of the bottlenecks Cocoon has is the decision process, or the
> time spent in the sitemap. With a declarative sitemap, we can
> have the equivalent of URL rewriting so that we can access the
> Reader info up front.
>
> Currently, one way of optimizing the Sitemap is to place often
> requested things first. I.e. your image matchers would perform
> better if placed first in the pipeline. However, they look nicer
> when they are placed last.
>
> We need a Sitemap that has a decision time that is fairly
> constant--as opposed to the length depending on the position
> in the sitemap.
Yes, you are right, we need a way to address this, but I really can't
find one.
I mean: having wildcarded hashmaps is something that I wouldn't know how
to algorithmically design.
Any idea?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by giacomo <gi...@apache.org>.
On Fri, 12 Apr 2002, Berin Loritsch wrote:
> Berin Loritsch wrote:
> > Stefano Mazzocchi wrote:
> >>
> >> But I think Berin touches a few serious design issues
> >> (overcomponentization, role of cache control, component isolation) that
> >> we must seriously consider.
> >
>
> I think you also missed one of the points. That is the current
> implementation of the Sitemap *pretends* to declarative when in
> fact it is truly procedural in the implementation.
We are free to have another implementation for it today as the Sitemap
is a component of type Processor.
> I think we should choose an approach for each type of Sitemap.
> Using my definition of Sitemap, we can have the current sitemap,
> the flowmap, or a proprietary map (nice place for a compiled
> Cocoon Block, eh?).
>
> I'm not saying it needs to be done for Cocoon 2.1, but soon.
> We should have a declarative sitemap, and a procedural one.
>
> One of the bottlenecks Cocoon has is the decision process, or the
> time spent in the sitemap. With a declarative sitemap, we can
> have the equivalent of URL rewriting so that we can access the
> Reader info up front.
The Wyona CMS uses a nice approach I've never thought of by using a tree
of sitemaps. This way search time can be split up from a linear way to a
tree based way. Of course one has to do it by hand today.
> Currently, one way of optimizing the Sitemap is to place often
> requested things first. I.e. your image matchers would perform
> better if placed first in the pipeline. However, they look nicer
> when they are placed last.
Exactly, this can be done by a subsitemap because your images often have
their own URI space they live in. Placing a map:mount at the top of your
root sitemap doesn't clutter it up too much.
> We need a Sitemap that has a decision time that is fairly
> constant--as opposed to the length depending on the position
> in the sitemap.
I can see what you mean but also I see the concept of the Matcher
abstraction vanishing by that approach. For a speedup of search time one
needs to group Matchers of the same type (URIMatcher, TimeOfDayMatcher,
etc.)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>>
>> But I think Berin touches a few serious design issues
>> (overcomponentization, role of cache control, component isolation) that
>> we must seriously consider.
>
I think you also missed one of the points. That is the current
implementation of the Sitemap *pretends* to declarative when in
fact it is truly procedural in the implementation.
I think we should choose an approach for each type of Sitemap.
Using my definition of Sitemap, we can have the current sitemap,
the flowmap, or a proprietary map (nice place for a compiled
Cocoon Block, eh?).
I'm not saying it needs to be done for Cocoon 2.1, but soon.
We should have a declarative sitemap, and a procedural one.
One of the bottlenecks Cocoon has is the decision process, or the
time spent in the sitemap. With a declarative sitemap, we can
have the equivalent of URL rewriting so that we can access the
Reader info up front.
Currently, one way of optimizing the Sitemap is to place often
requested things first. I.e. your image matchers would perform
better if placed first in the pipeline. However, they look nicer
when they are placed last.
We need a Sitemap that has a decision time that is fairly
constant--as opposed to the length depending on the position
in the sitemap.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> Stefano Mazzocchi wrote:
> > Berin Loritsch wrote:
> >
> >>Coming to a theater near you, Cocoon 2.1: Same Plot, Different Story!
> >
> >
> > Oh, I love it, love it, love it. :)
> >
> > Now, let's get nasty! how about XSLT-transforming the sitemap into Jon
> > Bosak Play DTD :)
>
> I'm not familiar with Jon Bosak :(
Oh, God! Jon Bosak is the guys who started the XML thing, the 'father of
XML' so to speak. Ask Google :)
> >
> > A sidenote: I'm pretty sure that everybody was laughing so loud that all
> > your points about refactorization was not really taken seriouly.
>
> Probably, but it was an example of analyzing Cocoon with the "Play"
> analogy that I was introduced to in Avalon.
:) I remember the night when Federico and I came out with that metaphor
to explain it to Pier. Gosh, I wonder what we could do now if we were
all still living in the same city :(
> >
> > But I think Berin touches a few serious design issues
> > (overcomponentization, role of cache control, component isolation) that
> > we must seriously consider.
>
> Those are the biggest beefs I have with Cocoon right now. In my view of
> the world, the existences of a Cache should be invisible to the anybody
> who is not specifically tuning it. We should notice its existence
> solely by the virtue of our page loads being faster.
Oh, yes, SoC at last.
But tell me: where do you see the problem with this approach? I normally
don't have to do anything on my cache and it's pretty transparent to me.
> The Overcomponentization is a big problem. Unless we start keeping an
> eye on it now, we will *never* get around to fixing it.
I wouldn't be that drastic, but I agree that Cocoon suffers from
overcomponentization (but it's really hard to balance things out the
first time so I'm not that worried, look how many years it took us to
get Avalon right enough to be useable).
> >
> > I only think that if we do this for 2.1 it will take forever for us to
> > reach a final release... this is the reason why I was considering
> > componentization refactoring to happen for 2.2 at least.
> >
> > What do you think?
> >
>
> I'm not saying we should go through and implement the COcoon
> Application COmponentarchitecture now. I am saying we need to quell any
> further unnecessary componentization as we are now busting at the seams.
Agreed.
> What I would like to see is that all _optional_ components be broken out
> into little "mini" projects with their associated classes all in one
> place. Kind of like what we recently did with Excalibur. In fact, when
> we finally get the bugs worked out of the dependancy system, I'm sure
> you can adopt the recursive dependancy build system in Excalibur for the
> Cocoon components.
Hmmm, interesting, sounds much like what Ovidiu was proposing... but I
think this goes so close of the refactorization what we'll need to
perform for blocks that I restate that I wouldn't want to do it twice.
> That way, the _only_ thing in the cocoon.jar is the core essential
> Cocoon components. All things optional are in separate jars so that we
> can create an install that is minimalist.
I don't think there is anybody against this, Berin, we are just trying
to find the best and more future-proof way to do this
refactoring/recomponentization
..
> Another thing that it allows us to do is start considering the role of
> the sitemap in regards to dynamic loading of jars. We currently let the
> servlet engine load all jars associated with a webapp. If we want true
> pluggability, we need to let subsitemaps load their own set of jars so
> that we can have true component isolation. Also, so that when we come
> up with the formal Cocoon Application ComponenT Infrastructure (CACTI?)
> or whatever we call it, we also have the component loading
> infrastructure in place.
Again, read my proposal on Cocoon Blocks and you'll see that the entire
CACTI that you proposed is already included in that design.
> I don't think that is unreasonable. It is a good first step toward the
> componentization process, allowing us to attack one aspect of it and
> provide some real feedback before we add in the application component
> infrastructure.
I say we do both at once, since they more or less require the same
machinery.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by Matt Sergeant <ma...@sergeant.org>.
On Friday 12 April 2002 1:38 pm, Berin Loritsch wrote:
> Those are the biggest beefs I have with Cocoon right now. In my view of
> the world, the existences of a Cache should be invisible to the anybody
> who is not specifically tuning it. We should notice its existence
> solely by the virtue of our page loads being faster.
I take completely the opposite viewpoint. I've developed serious high
scalability web applications. I've seen other people do the same. Caching is
almost *never* identical across web applications. It's almost always specific
to the actual application.
No, the cache should simply be another part of the pipeline. User
implementable. User definable. With some nice defaults to make life easy.
--
<:->get a SMart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Posted by giacomo <gi...@apache.org>.
On Fri, 12 Apr 2002, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
> > Berin Loritsch wrote:
> >
> >>Coming to a theater near you, Cocoon 2.1: Same Plot, Different Story!
> >
> >
> > Oh, I love it, love it, love it. :)
> >
> > Now, let's get nasty! how about XSLT-transforming the sitemap into Jon
> > Bosak Play DTD :)
>
> I'm not familiar with Jon Bosak :(
>
> >
> > A sidenote: I'm pretty sure that everybody was laughing so loud that all
> > your points about refactorization was not really taken seriouly.
>
> Probably, but it was an example of analyzing Cocoon with the "Play"
> analogy that I was introduced to in Avalon.
>
> >
> > But I think Berin touches a few serious design issues
> > (overcomponentization, role of cache control, component isolation) that
> > we must seriously consider.
>
> Those are the biggest beefs I have with Cocoon right now. In my view of
> the world, the existences of a Cache should be invisible to the anybody
> who is not specifically tuning it. We should notice its existence
> solely by the virtue of our page loads being faster.
Ehm.. the cache is almost transparent for a user now (the exception is
XSP). If you work with XML, XSLT only you'll never get in touch with
cache aspects, or do I missed something?
> The Overcomponentization is a big problem. Unless we start keeping an
> eye on it now, we will *never* get around to fixing it.
Yes, this is true. We should separate the sources into smaller pieces
and hopefully see where those components are which can be rewritten as
either helper/utility classes or maybe even merge them with others.
> > I only think that if we do this for 2.1 it will take forever for us to
> > reach a final release... this is the reason why I was considering
> > componentization refactoring to happen for 2.2 at least.
> >
> > What do you think?
> >
>
> I'm not saying we should go through and implement the COcoon
> Application COmponentarchitecture now. I am saying we need to quell any
> further unnecessary componentization as we are now busting at the seams.
>
> What I would like to see is that all _optional_ components be broken out
> into little "mini" projects with their associated classes all in one
> place. Kind of like what we recently did with Excalibur. In fact, when
> we finally get the bugs worked out of the dependancy system, I'm sure
> you can adopt the recursive dependancy build system in Excalibur for the
> Cocoon components.
Not even the optional component. I can see that we split up the source
using the following approach (as a first step):
core/
environment/
servlet/
cli/
components/
...
1) Break out everything that make the o.a.c.Cocoon class compile into
the core package.
2) Isolate the different environments into a sub tree. I mean
separating the servlet environment from the cli environment can reduce
the size of a deployed Cocoon for the intended use. So Avalon and other
projects which build their site and docs using Cocoon don't need a
servlet environment. Those which use Cocoon in a servlet env don't need
the cli stuff.
3) Start separating out some very basic sitemap component
implementation (like the Reader, FileGenerator, XMLSerializer) to
finally enable testing the stuff from 1) and 2).
4) Start separating other components. One way could be to separate
components based on the optional jar list (FOP components, DELI
components, Lucene components, Velocity components, etc.)
I'm sure the steps above will be repeated in cycles to beak out the
right stuff but could lead to clearly (or at least better) separate
things.
> That way, the _only_ thing in the cocoon.jar is the core essential
> Cocoon components. All things optional are in separate jars so that we
> can create an install that is minimalist.
Yes, see above for a way to go into that direction.
> Another thing that it allows us to do is start considering the role of
> the sitemap in regards to dynamic loading of jars. We currently let the
> servlet engine load all jars associated with a webapp. If we want true
> pluggability, we need to let subsitemaps load their own set of jars so
> that we can have true component isolation. Also, so that when we come
> up with the formal Cocoon Application ComponenT Infrastructure (CACTI?)
> or whatever we call it, we also have the component loading
> infrastructure in place.
Exactly, this has beed discussed by Stefano and me when he was here at
my place two weeks ago. I think that the Cocoon core must be able to
build a ClassLoader instatiated with the set of jars described in the
yet to be defined Cocoon Block Descriptor Language (CBDL) for each
Cocoon Block. There is the need to have a ComponentManager to be build
up with the components mentioned in the Cocoon Block Description (CBD)
for private components for each Cocoon Block as well.
For the exported components of the deployed Cocoon Blocks I see two
ways of making them available to the other Cocoon Blocks:
1) Have a root CM populated with the exported components from each
Cocoon Block.
2) Populate the CM for each Cocoon Block with components the Cocoon
Block in question depoends on.
In 1) we choose a lazy way of collection all available components into
one CM. The approach in 2) makes access to components possible exactly
as mentioned in the CBD for the block.
> I don't think that is unreasonable. It is a good first step toward the
> componentization process, allowing us to attack one aspect of it and
> provide some real feedback before we add in the application component
> infrastructure.
I think it may be a plan to go further.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org