Subject: Re: SLPGet/SetProperty Memory Management

From: James Kempf <[email-masked]>
Date: Fri, 23 Jun 2000 08:15:41 -0700 (PDT)

I'll write the bis draft. I presume it is a complete update, and
not just errata.

		jak

>Date: Fri, 23 Jun 2000 10:14:36 +0200 (MET DST)
>From: Erik Guttman <[email-masked]>
>Subject: Re: SLPGet/SetProperty Memory Management
>To: James Kempf <[email-masked]>
>Cc: [email-masked]
>MIME-Version: 1.0
>
>
>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.
>
>> 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. 
>
>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: james woodyatt <[email-masked]>
Date: Fri, 23 Jun 2000 15:31:50 -0700

> I'll write the bis draft. I presume it is a complete update, and

While we're reviewing the content of RFC 2614...

I would suggest an amendment to make the SLPSetProperty() C-language
function return an SLPError result, which would potentially be SLP_OK,
SLP_MEMORY_ALLOC_FAILED or SLP_NOT_IMPLEMENTED.  Are there any other
results that could make sense?

And on a related note: unless something unexpected happens, I suspect
Enron will let me publish the code and documentation I've written
which adds Perl to the list of languages for which there is an API to
write applications of SLP.  However, the Perl community can and does
herd its own camels.

I submit that a line should be drawn at C and Java language bindings
in the amendments.  A "procedural" language and an "object-oriented"
language are probably enough.  Anyone think otherwise?

-- 
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: Tue, 27 Jun 2000 10:45:21 -0400 (EDT)

On the topic of amending RFC 2614: 

  We (Dave McCormack and I) have noticed that the API provides very little
attribute support, this lack puts the onus of attribute creation/parsing
on the shoulders of the application programmer. It also means a fair
amount of code duplication between applications. 
  
  The following recommendations aim to avoid that:

(In terms of the C API)

  What about adding an extra type, SLPAttributes, that would have a number
of associated functions:

 SLPAttrsSet(SLPAttributes attr_h, const char *tag, const char *val)
 SLPAttrsGet(SLPAttributes attr_h, const char *tag, val **val)

  When it came time to send the register a service, one of the following
could be done:

 SLPRegAttr(..., SLPAttributes attr_h,...)

(I don't mean a variable-length arg. list, I mean the other attributes =)

 When requesting attributes, a SLPAttributes handle would be passed into
the callback. An iterator would be provided (SLPAttrIterator) to allow the
application to do:

  while (SLPNextAttr(attr_iter, &key, &val)) {
     ...
  }

 Additional functionality could include type checking against a template:

 FILE *f;
 SLPAttributes attr_h;

 SLPAttrAlloc(&attr_h);

 f = fopen("template.txt", "r");

 SLPSetTemplate(attr_h, f);

 ...

 Subsequent calls to SLPAttrSet() would be able to return error codes that
pertain to type checking, including:

 SLP_TYPE_ERROR -- If the type is wrong. 
 SLP_TAG_ERROR -- If an illegal tag is used. 

Comments?

e