IPP Mail Archive: IPP> RE: SVRLOC WG IMPORTANT: SLPv2 next

IPP> RE: SVRLOC WG IMPORTANT: SLPv2 next step?

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Aug 31 2000 - 13:01:42 EDT

  • Next message: McDonald, Ira: "RE: IPP> NOT - Last word for now on Notification delivery methods"

    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