Subject: Re: Attribute API

From: James Kempf <[email-masked]>
Date: Wed, 28 Jun 2000 11:49:03 -0700

Sure, I think this is fine. You could simply include the attribute API
as "value added" for OpenSLP and ultimately, if enough people start
using it, Sun and everybody else will put it in.

I agree with you about the work involved on the SA side. It is alot
easier with the Java API.

Re. wireless, we are thinking of releasing a wireless printer discovery
daemon we've done with the mini-slp release. It would require a
specific print driver and it is for Win32 but it gives the idea.

		jak
>
>On Tue, 27 Jun 2000, James Kempf wrote:
>...
>> a fact, however, that it will be difficult to impossible to
>> get Sun to implement this or any other major change in the
>> SLP API. Minor tweaks like improving multithreading for 
>> SLPGet/SetProperty() are doable, but any major changes
>> will probably not happen unless there is some major customer
>> demand.
>
>  Alright. I was thinking of this in terms of the OpenSLP api: I'd like
>more services to be made SLP-aware, and I think the easiest way to do this
>is to make the SLPification process as easy as possible. On the client
>side, this is no problem (the API is very sufficient in that area), but on
>the SA side the API is a bit weaker:
>
>  The attribute marshelling functionality will always be repeated, the SA
>must _always_ take internal data, convert it to strings, escape it, copy
>it into a bigger string, and then pass that string into the API. This is
>basically drudge work that will always have to be done by an SLP service,
>so it makes sense to farm it out to the API. Not only is it drudge work,
>but it's inefficient (three mallocs, three string copies, one string
>length, and one string parse) and error prone.
>
>
>  Since we're looking at this in terms of an open source project, we want
>to make SLP as usable/implementable as possible[*]. Ideally, making a
>service SLP aware should be one day process. In its current state, the
>attribute management will take up to a week. 
>
>
>  I guess our goal is SLP advocacy (in the name of the greater good: IP
>mobility and pervasive (calm) computing). We would like as many services
>to be SLPified as possible. IMHO, the API's weak attribute manipulation is
>a barrier to gaining acceptence from the wider community.
>
>
>e
>
>--
>* - As I mentioned, we want to use SLP for resource discovery in wireless
>networks. SLP fits our needs well, but there are no SLP-aware services, so
>we need to make SLP-aware services. Since we don't have time to SLPify all
>services, we want other people to SLPify their own services. 
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jun 2000 11:07:55 -0700

> easier with the Java API.

BTW, attribute manipulation in Perl is pretty breezy too.

If I had the proposed attribute manipulation API to work with, I guess
I could wrap some Perl-ish thing around it.  But I would still want to
write native Perl code for managing attributes anyway.  Attribute
lists seem to fit naturally into Perl hashes, and the code for
converting to and from their string representation is painfully
simple.

At EBSS, we have written our own attribute manipulation module.  The
RFC didn't specify an API, and the Mini-SLP implementation we are
using doesn't seem to export one.  I expect to be able to swap in
another implementation of SLP (probably OpenSLP or Sun's
implementation in Solaris 8) without having to ditch our attribute
manipulation module.

Evan's proposed extension to the API wouldn't force the marriage of
his attribute manipulation layer with the protocol agent layer, so if
we swap out Mini-SLP for OpenSLP, we'll probably decide to ditch our
one-off module in favor of Evan's API only if the RFC explicitly
recommended it.

If an attribute manipulation API that didn't require any change to the
protocol agent API were added to OpenSLP and not to Sun's own
implementation, then I think that would give OpenSLP a potential
advantage on Solaris.  It wouldn't be the first time that LGPL'd
software found itself in competition with Sun's operating system--
however, avoiding that competition doesn't seem to me like a good
enough reason to add the extension to the amended RFC.

-- 
j h woodyatt <[email-masked]>  | "Never look at the trombones.
coder, foundation software        | You'll only encourage them."
enron broadband switching systems |     -Robert Strauss, on conducting