cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: Commentary (was Re: [Analysis] Cocoon, The Play)
Date Mon, 15 Apr 2002 19:37:02 GMT
> 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


Mime
View raw message