Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
>> That work was done very late in the release cycle, and it had
>> little design review even internally at the time (IIRC).
> 
> Am I correct that from the above I may conclude (given
> it enough review and field testing) it would be a candidate as far as
> you are concerned?

Sure, although if that means redoing into the net.jini namespace,
it will be worthwhile to have a discussion on the real value of doing so.

- Bob

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> My motivation is to include such an API as part of a Platform for the
> motivation given below (from my initial posting):

Sorry for being unclear, I understand that, the discussion I was
referring to was around the value of keeping everything in the
"platform" in the net.jini namespace.

- Bob

Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> That work was done very late in the release cycle, and it had
>>> little design review even internally at the time (IIRC).
>>
>> Am I correct that from the above I may conclude (given
>> it enough review and field testing) it would be a candidate as far as
>> you are concerned?
> 
> Sure, although if that means redoing into the net.jini namespace,
> it will be worthwhile to have a discussion on the real value of doing so.

My motivation is to include such an API as part of a Platform for the
motivation given below (from my initial posting):

"In case the Discovery related API and service provider selection would
have been a 'standardized' public API and mechanism, people can build on
top of that utilities. The configuration of Platform provided service
providers can then be left to the Platform implementors such as Seven
while they can still add their own service providers for cases not
supported by the Platform."

E.g. LookupDiscovery and LookupLocator implementations can be built on
top of such an API in a portable way, no need to drag all the com.sun or
future org.apache.river implementation code as is currently the case.
-- 
Mark