Subject: Re: New Drafts

From: James Kempf <[email-masked]>
Date: Thu, 21 Dec 2000 15:18:44 -0800 (PST)

>O.K, then why is the pcSrvType parameter needed at all?  Wouldn't we
>always know the service type by parsing the sceme of the URL?  Why would
>you ever need to use pcSrvType if there is always a 1 to 1 correleation
>between the URL and the type?  
>
>Take a call to SLPReg() where pcSrvURL = "ftp://ftp.acme.com",
>pcSrvType="weird.x" what is passed in the message?  Now, how do I
>de-register this thing with out possibly deregistering another
>registraion with pcSrvURL = "ftp://ftp.acme.com", pcSrvType="ftp"?
>

Suppose I want to register the service "ftp://ftp.acme.com" under
the service type name "service:file-server". pcSrvURL is "ftp://ftp.acme.com"
and pcSrvType is "file-server". When I go to deregister, because there
is a one to one mapping between type names and URLs (but not necessarily between
the URL's parsed scheme name as type name and URLs) then I only need
to provide the URL.

>I'm not trying to be critical, I'm just trying to understand.
>

No problem.

>Also, discovering scopes is not a care free process from a network usage
>point of view.  I suppose you could call SLPGetProperty() for
>net.slp.useScopes, but again, why should you have to.  I have SLPized
>several legacy services, and  I speak from experience when say that
>anything the API can do to minimize the amount of code required for SLP
>development will crucial to the increased adoption of SLP.  In the
>OpenSource world, project maintiners are much more eager to accept small
>patches that are easy to understand. 
>

As far as network usage goes, Solaris SLP maintains a cache of configured
and discovered scopes on the machine so that a UA doesn't need to go
beyond the local machine. When you call the API function for scopes,
it goes to the local cache, which is not the configured scopes however.

With regard to net.slp.useScopes, there is no requirement that any DHCP
scopes be added to this property. The property is only for statically
configured scopes. We should probably add something to the text to actually require
the property to reflect all configured sources. 

However, I still think letting the programmer shortcut is a good idea.

>> I don't like the idea of passing back a string that is not null terminated.
>> C strings should always be null terminated. If you want a simple attribute parsing
>> function, then maybe we can support something like strtok() but I would need to see a 
much
>> better description than the above.
>
>The reason I don't like the strtok() approach is because I wanted
>SLPParseAttrs() to be something that can be used from within the
>SLPAttrCallback -- without requiring an intermediate memory
>duplication.  strtok() modifies the parsed buffer (squashing delimeters
>with nulls).  strtok() is also not thread safe and a reentrant (
>strtok_r() ) still modifies the parsed string.  
>
>The attribute string returned by SLPAttrCallback is const and must not
>be modified.  This means that you have to duplicate the attribute list
>before parsing.  This duplication is almost always a wasted  buffer as
>you will most likely have to duplicate the value (again) before using
>it.
>
>Return of a pointer and a length means you do not have to destructively
>parse the attribute string and you do not have to force the caller to
>waste a call to malloc() and free() to temporarily hold a copy of the
>attrlist as you destructively parse it.  
>
>In addition, most string classes and string data structures provide very
>fast constructor methods which accept strings (buffers) in the form of a
>pointer and length. 
>
>Still,  I can't blame you for wanting to see all strings NULL
>terminated.  It does make you a little more comfortable.  In this case,
>what would you think about a function that returns a pointer to an
>allocated string?
>
>SLPError SLPParseAttrs(const char* attrlist,
>                       const char* id,
>                       char** val);
>
>Where val is the value of the requested id.  val would have to be freed
>by SLPFree().
>
> 

That's fine, as long as the string is a well formatted C string.

Can you send me documentation on the function in the format of the RFC? I'll
put it into the update.

		jak

---

From: Matt Peterson <[email-masked]>
Date: Fri, 22 Dec 2000 06:34:05 -0700

> the URL's parsed scheme name as type name and URLs) then I only need

I see how a 1 to 1 mapping between url and type resolves my concern, but
what I don't understand is how any sort of 1 to 1 mapping between url
and type can be enforced.  

For example what should a DA do if it already has a registration as
specified above (URL = "ftp://ftp.acme.com" SrvType =
"service:file-server") and receives another SrvReg with
URL=ftp://ftp.acme.com and SrvType="service:ftp".  Should the DA add the
new registration to its internal database or reject it because it
conflicts with another registration (i.e. breaks the one to 1 to 1
correlation between URL and type)?

If the registration is rejected what error code is returned and how can
developers be expected know what was previously registered so as to
avoid "ambiguous registration" errors?  If the registration is allowed
in the database, what should happen on receipt of a SrvDereg with
URL="ftp://ftp.acme.com"?  How does the DA know which registration to
remove from its internal database, or does it remove both?   No, it can
not remove both with out "cheating" one of the registrars and the DA
can't just remove one registration because it does not know which one to
remove.

Erik, maybe you can out here?

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]