> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
