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()
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 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 parameters, RFC 2614 says that this parameter may not be the empty string or NULL. 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 burdon 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.
The SLPSetProperty() is ignored
The SLPSetProperty() and SLPGetProperty() calls are impossible 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 the library and freed by the caller. The SLPSetProperty() call would still access with the data store in such a way that mutexes would be required to ensure that SLPSetProperty() and SLPGetProperty() were never used 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 or 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 will do just a well. This is why the vast majority of C APIs use NULL to indicate an ignored parameter or default value -- not the empty string ("").Incremental registrations an 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 very bad idea. With out doubt, it is best to instruct SLP developers to minimize when ever possible, the number of calls that ultimately generate SrvReg and SrvDereg messages. If dynamic data is to be represented, it is best do 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 then 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 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 "fresh" registration.
Addition of a very simple attribute parsing function
The following function is secretly included with OpenSLP and has proven to be very useful./*=========================================================================*/
SLPError 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
*/
/*=========================================================================*/