Divergence from RFC 2614
SLP Service URLs are required
SLP Service URL syntax is required for all functions that accept URL
strings. The following is a list of affected functions:
-
SLPReg
-
SLPDeReg
-
SLPDelAttrs
-
SLPFindAttrs
-
SLPParseSrvURL
-
SLPSrvURLCallback
The decision to require SLP Service URL syntax was made based on in
part
the following scenario:
Suppose that two calls were made to SLPReg with srvurls
and srvtypes of "192.168.100.2","http" and
"192.168.100.2","ftp".
Now the developer wants to deregister one service with out
deregistering
the other. How can it be done? The SLPDeReg call does not
have a service type parameter, so it would be impossible for the
underlying
implementation to distinguish between the two registrations. In an
attempt
to standardize, OpenSLP expects valid Service URLS.
OpenSLP requires strict Service URL syntax because a Service URL can be
treated as a unique database key that identifies a registered service.
Not requiring Service URL syntax allows for several ambiguities like
the
one mentioned above.
Scopelist may be the empty string ("")
In the calls where a scope list is accepted as a parameter, RFC 2614
says
that this parameter may not be the empty string or a NULL pointer
value. OpenSLP allows scope list to be NULL or the empty string. If the
empty string is passed in as a scopelist, then OpenSLP will use the
scopelist
the system administrator has configured for the machine. This saves
99% of all developers the time of calling SLPFindScopes and parsing the
result.
Scoping is almost entirely an administrative task that is only
required
for scalebility of the SLP wire protocol. Having to deal with and
understand scopes will be a burden to the large majority of
programmers. Unless they are writing some sort of SLP browser, they
will be very content
to use the scope that the machine is configured to use.
This extension by no means mandates the use of NULL or empty scope
strings. Programmers who want complete implementations of SLP
applications may indeed use the API to acquire knowledge about existing
scopes on the network, and then present a scoping choice (if more than
one is available) to the user.
The SLPSetProperty is ignored
The SLPSetProperty and SLPGetProperty calls are impossible to implement
in a way that would be both scalable and thread safe. The
SLPGetProperty
call could never be made thread safe unless return value was a pointer
to a buffer dynamically allocated by the library and freed by the
caller. The SLPSetProperty call would still access the data store in
such
a way that mutexes would be required to ensure that SLPSetProperty and
SLPGetProperty were never using the same buffers at the same time. Even
if a thread-safe data store were devised, the SLPGetProperty call
would be used so frequently during internal operations of the library
that
performance might be adversely affected due to mutex bottlenecking or
the
amount of processing required to resolve the attribute name to a value.
NULL and empty string are acceptable parameters
According to RFC 2614, NULL is not exceptable value for any parameter.
Instead programmers are instructed to passed the empty string "".
OpenSLP allows programmers to use either NULL or the empty string.
It is very easy to deal with both NULL and empty string in the
implementation,
and allows developers to write more familiar and slightly more
efficient
code. There should not be any reason why the compiler should be
required
to pass a pointer to a static constant empty string when NULL would do
just
as well. This is why the vast majority of C APIs use NULL, and not the
empty string, to
indicate an ignored parameter or default value.
Incremental registrations and de-registrations
The only reason I can think of ever wanting to expose the functionality
of incremental registration and deregistration is to represent dynamic
data via SLP attributes. I can think of a long list of reasons why
this is a very bad idea. Without a doubt, it is best to instruct
SLP developers to minimize whenever possible, the number of calls that
ultimately generate SrvReg and SrvDereg messages. If dynamic data
is to be represented, it is best to do it via a specialized protocol
optimized
for the given service. OpenSLP does not support incremental
registrations
and de-registrations via SLPReg and SLPDelAttrs because we have found
that when developers really learn what happens "under the SLP covers"
they
are very careful *not* to call them very often.
In addition to poor usage of network resources, incremental
registrations
and de-registrations require additional code that decreases the
efficiency
of, and increases the size and complexity of the OpenSLP API and agent
implementations.
The work around for this behavior involves the following:
-
Design application usage of SLP such that SLP is not used to store
great
quantities of data
-
Design application usage of SLP such that SLP is not used to store
dynamic
data
-
If the need does arise to add or remove an attribute from an existing
registration
simply re-register the service with new attributes as a "fresh"
registration.
Addition of a very simple attribute parsing function
The following function is included, without explicit documentation,
with the OpenSLP library, and has proven
to be very useful:
<>/*=========================================================================*/
SLPEXP SLPError SLPAPI SLPParseAttrs(
const char * pcAttrList,
const char * pcAttrId,
char ** ppcAttrVal);
/* Used to get individual attribute values from an attribute string
that */
/* is passed to the
SLPAttrCallback
*/
/*
*/
/* pcAttrList (IN) A character buffer containing a comma separated,
null */
/*
terminated list of attribute id/value assignments, in */
/*
SLP wire format; i.e.
"(attr-id=attr-value-list)"
*/
/*
*/
/* pcAttrId (IN) The string indicating which attribute
value to return. */
/*
MUST not be null. MUST not be the empty string ("").
*/
/*
*/
/* ppcAttrVal (OUT) A pointer to a pointer to the buffer to
receive
*/
/*
attribute value. The memory should be freed by a call */
/*
to SLPFree() when no longer
needed.
*/
/*
*/
/* Returns: Returns SLP_PARSE_ERROR if an attribute of the
specified
id */
/* was not
found otherwise
SLP_OK
*/
/*=========================================================================*/
>
Some .conf properties are ignored
See the OpenSLP Users Guide
for
more details.