Subject: SLPGet/SetProperty Memory Management

From: James Kempf <[email-masked]>
Date: Thu, 22 Jun 2000 09:40:11 -0700 (PDT)

>The OpenSLP workaround for the dangerous pointer problem is not to honor
>SLPSetProperty().  This way we can be sure that the pointers returned by
>SLPGetProperty() will not be changed out from underneath the callers of
>SLPGetProperty().
>
>

Well, this defeats the purpose of the function, which is to allow people
to change properties. There are some properties that were designed
to be changed, like the net.slp.typeHint property, which allows
an SA API client to specify the service type to look for when
doing SAAdverts. 

>A better API would be:
>
>char* SLPGetProperty(const char* propertyName, 
>                     char** propertyValue);
>
>/* memory is allocated by the library but freed with SLPFree() by the
>caller */
>
>

We can certainly change the API to do this, if it looks like it is what
people want. Going toward draft standard, we can reissue the RFC 
in corrected form if particular issues like this come up, and also
to correct typos.

		jak

---

From: Matt Peterson <[email-masked]>
Date: Thu, 22 Jun 2000 11:10:20 -0600

> an SA API client to specify the service type to look for when

I agree that SLPSetProperty() would be very useful.  The first thing
that comes to mind is setting timeouts.  I know of numerous developers
that would like to set VERY agressive timeouts for DA discovery and for
general multicast discovery (net.slp.multicastTimeouts, etc) because
they are expecting to run on fast networks.  The list goes on...

Anyway, we felt like it would be best to protect the developer.  If
SLPSetProperty() was functional, there would really no way that a
developer (or the library itself) could ever trust a pointer retuned
from SLPGetProperty() - especially in multi-threaded environments. 
Disabling SLPSetProperty() was a protective measure, not a statement of
it's usefulness.  

> in corrected form if particular issues like this come up, and also

You can count OpenSLP as one project that would like to see the
SLPGetProperty() API changed.  If the new API is similar to the one
above, we would be able to enable SLPSetProperty() and syncronize the
library data store in a way that the library could continue to be
reentrant.

Matt

---

From: Evan Hughes <[email-masked]>
Date: Thu, 22 Jun 2000 13:19:35 -0400 (EDT)

> they are expecting to run on fast networks.  The list goes on...

 Yep. I'm thinking about command-line utils to find stuff like
http-proxies on intranets. I'd love to be able to set the timeout to
something "aggressive" like 1 or 2 seconds. 

...
> > >/* memory is allocated by the library but freed with SLPFree() by the

Make that:

SLPError SLPGetProperty(const char* propertyName,
                     char** propertyValue);

=)

> library data store in a way that the library could continue to be

 Count SSB as numero deux.

e

---

From: james woodyatt <[email-masked]>
Date: Thu, 22 Jun 2000 10:37:26 -0700

> SLPError SLPGetProperty(const char* propertyName,

I was going to point this out as well.

>  Count SSB as numero deux.

I agree with the arguments for making this change.  I can live for
awhile at least with the current API, and even with OpenSLP's
disabling of the SLPSetProperty function, but in the long run, I'll be
happier if the API is changed.

Even in single-threaded environments, the current API exposes me to
the risk that my developers might inadvertantly cache property values
and trip over the dangling pointer issue with SLPSetProperty().

-- 
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

---

From: Evan Hughes <[email-masked]>
Date: Thu, 22 Jun 2000 14:10:14 -0400 (EDT)

How often can SLPAttrCallback() expect to be called? If I call
SLPFindAttrs() with a URL, am I guarenteed that the callback will be
called at most once? 

If I call SLPFindAttrs() with a type, how do I know which service is
associated with each set of attributes?

e