Hi,
I think I agree with Evan below.
In IPP (Internet Printing Protocol), we're currently
considering using LDAPv3 String Search syntax to add
filters for Job and Resource objects. Given the
discussion on the SLP WG mailing list, we're wondering
about choosing a profile (subset) of the full LDAPv3
filters.
Information that supports a reasonable implementation
cost for full LDAPv3 filters is important, so I've
cross-posted my reply to the IPP list.
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
-----Original Message-----
From: Evan Hughes [mailto:hughes@lab43.org]
Sent: Wednesday, August 30, 2000 1:34 PM
To: Erik Guttman
Cc: srvloc@srvloc.org
Subject: Re: SVRLOC WG IMPORTANT: SLPv2 next step?
On Wed, 30 Aug 2000, Erik Guttman wrote:
> So are you happy with the slpv2bis-01 draft?
No:
With regards to section 3.1.1:
I do not feel that the issues raised regarding the complexity of
implementing LDAPv3 search filters justifies the simplification of SLP
search facilities. My reasons follow:
* I have implemented the LDAPv3 search filter for OpenSLP (which should
be included Any Day Now, see
http://www.nexus.carleton.ca/~hughes/filter.tgz for the implementation),
and found the task doable. Implementing the logical operators was the
easiest part, since the code for `&` is almost identical to `|`s. The only
difficulty I found was in implementing the "leaf" operators (=,=*,<=,>=)
since there are five types of variable. The implementation took roughly 3
days (plus another 5 for refactoring), but it must be noted that I am have
only moderate experience.
* In order to implement the `|` or `!` operators, some form of recursion
on the filter string is necessary. Arbitrarily limiting the filter string
to contain one `&`, while allowing an unlimited number of `|`s is
nonsensical, as `&` will become a special case for parsing -- increasing
complexity.
* The removal of any operator limits SLP's applicability. Before causing
such a dramatic reduction in SLP's potential functionality, it should be
shown that the `&` operator greatly increases the complexity of filter
parsing. This has not been done.
* To say that "Complicated logical queries for services have not proven
useful" is more of a statement about the uses of SLP than on the
applicability of the operator itself. As SLP gains acceptance, more
complex uses of it will be found. As more complex uses are found, more
complex filtering will be necessary.
* At some point during the discussion somebody mentioned the relative
complexity of each of the entities on the network. As far as I recall,
complexity was a spectrum, with UA/SA's being simple (possibly
computationally bound), and DAs being complex (possibly with greater
memory/processor resources). Removing the `&` weakens the role of the DA,
since any UA that wishes to use multiple `&`s will have to do client side
attribute checking. This does not follow with the aforementioned
resource model.
(I feel like I should get a t-shirt saying "Save the &". =)
Before stating that the LDAPv3 filters make SLP difficult to implement,
it may be a good idea to find some supportive references. I was able to
code and then refactor the search filter in less than two weeks.
Further, I don't see the point of removing the eliding of
leading/trailing white space. Again, the code of eliding is relatively
simple, and it avoids pesky white-space errors.
In general:
Reducing SLP's functionality will only harm SLP's utilization. As it is,
SLP has not gained widespread acceptance (OpenSLP is the first opensource
implementation of SLP. This indicates that few oft-used services use
SLP). Weakening SLP's functionality condemns the protocol to disuse.
Consider the functionality in terms of amortization. Since searching will
usually be done in DAs, and DAs will be a "build once, use often"
application, the minimal cost of implementing a few useful features will
be averaged across many running DAs. But UAs, which require these search
filters, will be legion (there should be a UA in every web-browser, time
daemon, printer application, mail client, news client, networked game,
networked application, etc), meaning that there are going to be thousands
of people using SLP in UAs.
Does it make sense to favour the few DA developers, or the many UA
developers? Do you "simplify" (I still doubt any significant
simplification would result, but let's pretend =) the task of the
minority, only to condemn the many to hacks and work-arounds?
e
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 13:11:03 EDT