Subject: Re: SVRLOC WG IMPORTANT: SLPv2 next step?

From: Evan Hughes <[email-masked]>
Date: Wed, 18 Oct 2000 13:31:58 -0400 (EDT)

On Wed, 18 Oct 2000, James Kempf wrote:
...
> The issue with ! is not the parsing code, but the evaluation code.
> My experience is that it requires a whole additional table in the
> database in order to get optimized operation.

How does a database fit in?

e

---

From: James Kempf <[email-masked]>
Date: Wed, 18 Oct 2000 10:10:44 -0700 (PDT)

>Functional predicate code (this code deals with locating operators and
>performing boolean operations -- it does not include the 61 lines of
>support functionality):
>     
>          217 lines (24 of which are comments, another 27 are blank) = 166
>
>Boolean operations (just the prefix):
>
>           60 lines (8 are comments, 10 are blank) = 42
>
>Lines per boolean operator:
>                         &       23 (3 c, 4b) =  16
>                         |       23 (3 c, 4b) =  16
>                         !       11 (1 c, 1b) =  10
>

The issue with ! is not the parsing code, but the evaluation code.
My experience is that it requires a whole additional table in the
database in order to get optimized operation. I'm sure someone with
extensive database experience could do a much better job, but I still
think the evaluation is expensive to implement. Also, I agree with
Erik's assessment that one rarely wants to find a service that does not
do something.

The issue with | is less clear. My experience is that the parsing code
was not particularly difficult to implement, and I can see cases where
it may be useful (e.g. I'm willing to take 600 dpi or 1200 dpi printing).
However, it is one more thing to implement and if the working group
feels that it should be dropped, then I've got no objection to dropping
it.

> I would like to make the following suggestion:
>  * Since LDAPv3 filters allegedly (*grin*) discourage use of SLPv2, make
>them optional. Allow SA/DAs not to implement them. Have them report that
>when they send the DAadvert (or whatever the response is). 
>  * Allow query forwarding from filterless DAs to filtered DAs using mSLP. 
>

This is an attractive possibility, especially since there are already
implementations that contain these operators.

		jak