Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <461159D1.1000206@cheiron.org>
Date: Mon, 02 Apr 2007 21:30:25 +0200
From: Mark Brouwer <mark.brouwer@cheiron.org>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Fundamental problem in handleUnicastDiscovery for SSL and
 Kerberos
 and more
References: <460A5B82.5040104@cheiron.org> <460AAC38.8090405@Sun.COM>
 <460B6D86.7000908@cheiron.org> <461155E2.8020208@Sun.COM>
In-Reply-To: <461155E2.8020208@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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