river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more
Date Mon, 02 Apr 2007 19:30:25 GMT
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

Mime
View raw message