Vadim Gritsenko wrote:
>>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:
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
