LiveTribe-SLP-RFC2614

Why LiveTribe :: SLP does not implement RFC 2614

RFC 2614 defines the language bindings for C and Java for the SLP application programming interface (API).
However, speaking of the Java part only, RFC 2614 has several drawbacks that make it not possible to implement a standard and portable API.

Java APIs are controlled by the Java Community Process (JCP). One of the Java Specification Requests submitted to the JCP is JSR 140, "Service Location Protocol (SLP) API for Java".
This JSR has been withdrawn and, unless a new JSR is submitted, there is no standard API for SLP in Java.
Each implementor is allowed to implement RFC 2614 using its own package structure, and while class names are defined by RFC 2614, it is obviously not enough.

Furthermore, what is defined in RFC 2614 is somewhat old (dates back to 1999) and has not been updated to reflect improvements of the Java API that could benefit an SLP API.
Improvements of this kind include the use of Java2 collection framework classes like java.util.List or java.util.Iterator instead of java.util.Vector or java.util.Enumeration.

The RFC 2614 Java API also suffers, in my humble opinion, from a few design issues.
Class ServiceLocationEnumeration is used to return in certain methods an enumeration of ServiceTypes, in other methods an enumeration of ServiceURLs. This may confuse users and does not provide type safety. Furthermore, the blocking semantics of ServiceLocationEnumeration.next() (the method should block if results are not available) unnecessarily complicates user code.

There is no abstraction for the scopes, though scopes are case insensitive and have a Set semantic (no duplicates): RFC 2614 requires you to specify them in a java.util.Vector.

Locator.findServices() is the central method that allows client applications to discover services on the network. RFC 2614 states that it must return a ServiceLocationEnumeration of ServiceURL. If the client is also interested in the attributes of the discovered services, it must issue other (network) calls to retrieve the service's attributes.
This is obviously inefficient and acknowledged by RFC 3059 (Attribute List Extension for SLP), that specifies an SLP message extension that returns attribute information piggybacked on a reply of a service request. However, Locator.findServices() has no way of returning this information since it must return ServiceURLs only.

For these reasons, the LiveTribe SLP module defines its own SLP API. It is certainly possible to implement an RFC 2614-like API on top of the LiveTribe SLP API, but exposing the users to the RFC 2614 API opens the risk of limitating and complicating their code, and does not provide any portability of the user code across SLP implementations.