Subject: Re: SLPGet/SetProperty Memory Management

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

If everybody is agreed that SLPGetProperty should allocate
memory so that it can be freed from SLPFree, then I would suggest
that we simply consider it part of the standard and implement it that
way. I'll put in a change request for Sun's implementation, which,
as far as I know, is the only current functional implementation of 
SLPSetProperty Otherwise, OpenSouce SLP will end up with a nonfunctional 
SLPSetProperty function. I don't think there should be any backwards
compatibility issues except to plug a potential memory leak.

When we update the RFC, I'll make sure that it gets in.

		jak

---

From: Erik Guttman <[email-masked]>
Date: Fri, 23 Jun 2000 10:14:36 +0200 (MET DST)

Folks,

I see the synchronization issue.  You can't safely hand out a const
pointer from the library to something which can be changed at any 
time.

> way. 

What we should do is start an internet draft which explains all the 
desired changes to the API. Then we can discuss it, implement to it
and in the end decide to go with it.

> When we update the RFC, I'll make sure that it gets in.

The internet draft can be an update to the RFC, when we're all agreed
on it.  Its an informational RFC, so it is very easy to have it published.
It need not be a WG document.

Who would like to take on writing the draft-<who>-svrloc-rfc2614bis-00.txt?

Erik

---

From: Evan Hughes <[email-masked]>
Date: Fri, 23 Jun 2000 09:29:40 -0400 (EDT)

On Fri, 23 Jun 2000, Erik Guttman wrote:
...
> Who would like to take on writing the draft-<who>-svrloc-rfc2614bis-00.txt?

  What would writing the draft entail? Is is simply a modification of
2614, or is it a whole new document?

e

---

From: Erik Guttman <[email-masked]>
Date: Fri, 23 Jun 2000 15:53:46 +0200 (MET DST)

> 2614, or is it a whole new document?

That's up to you :-)

Seriously though, I recommend we come up with a list of deltas to 
2614 for now.  This draft would document where the document has to
be ammended so someone could pick up the RFC and the draft and know
just what to do.

Its much easier to review a short draft than an entire API spec.

Once we all agreed on the draft, it would probably be best to merge
the changes into 2614 and come up with a new version of the API RFC.
The only changes would be the ones we agreed to, so it'd be a
reasonably contained task to merge and review them.

Erik