Subject: Re: Java SLP API

From: James Kempf <[email-masked]>
Date: Wed, 9 May 2001 09:22:12 -0700 (PDT)

Sean,

>	The Java API is a little more difficult. First, there
>isn't a requirement to recompile on different platforms. Second,
>the specification of the API makes it difficult to write vendor
>independant code and swap out implementations. RFC 2614 doesn't 
>specify a package containing interfaces which are to be implemented 
>by vendor specific code. Finally, I didn't find a Java implementation
>which supports OpenSLP. This is why I was looking into interoperability
>between client libraries and daemons.
>

One of the reasons for having a package name that reflects the
organization implementing it was to address this issue. So, in
effect, the entire API is defined in a package that has a vendor
specific implementation.

>	I would be interested to what the implications of
>a slightly different Java API would be. For example (the
>package was chosen for example purposes only):
>	
>package javax.slp;
>
>public interface ServiceLocationManger {
>	void init(java.util.Properties p) throws ServiceLocationException;
>	Locator getLocator(Locale local) throws ServiceLocationException;
>	Advertiser getAdvertiser(Locale locale) throws
>		ServiceLocationException;
>}
>
>where the developer would do the following:
>
>	String impl = "com.sun.slp.ServiceLocationManger";
>	try {
>		javax.slp.ServiceLocationManager m =
>(javax.slp.ServiceLocationManager)Class.forName(impl);
>		m.init(p);
>		javax.slp.Locator l = m.getLocator(...);
>	}
>	catch (Exception ex) {
>	}
>
>This would let the developer swap out Java implementations to
>correspond with the SA daemon running on the platform.
>

I think I see what you are getting at. The code using the API has  to import
the class names from some package, and if the package is the different
for each vendor, then the application code becomes nonportable.

When we were writing the API, I tried to generate some interest in 
a common package name and standardizing the API through the Javasoft
standardization process, but there was none. So I dropped it.
In order to use javax, we would have to write a JSR and go through
the Java standardization process. We could also change the package
name to something like org.ietf, but I think there would be
resistance from vendors that already have deployed product. 

		jak