Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D4910C9.4050902@zeus.net.au>
Date: Wed, 02 Feb 2011 18:07:37 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: MarshalledServiceItem
References: <4D45C8A5.6010309@zeus.net.au>
	 <52044E7A-F5A2-4470-AA5F-9922C0328639@wonderly.org>
	 <AANLkTi=j8FTTisHLAD_d14NzZy10PTW=E1fm7-TKFWa2@mail.gmail.com>
	 <4D485B3A.4050508@cox.net> <1296633015.23168.56.camel@mkleczek-laptop>
In-Reply-To: <1296633015.23168.56.camel@mkleczek-laptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Michal Kleczek wrote:
> On Tue, 2011-02-01 at 13:12 -0600, Gregg Wonderly wrote:
>   
>>> Digging through classes belonging to a service implementation that is
>>> designed to be encapsulated/not your concern? Does that sound right? I gotta
>>> say, it sounds horribly invasive, very hacky and speaks of an overly complex
>>> solution as the result of treating symptoms, not problems.
>>>       
>> Okay, I want to go through the problems that I was dealing with, the attributes 
>> of the current mechanisms, and how I inserted points of control to manage these 
>> issues.
>>
>> First, let's look at the simple client mechanisms I wanted to have.  I have a 
>> desktop environment, which does lookup, and then shows treeviews of services 
>> based on "machine"->"group"->Service Instance structure.  The deployed services 
>> contain Entry objects that provide values for these three name spaces.  Since I 
>> need to look at these, they can not be preferred by the service or I can't read 
>> them.  There may be a subclass that the client has used, and that can be 
>> preferred no problem.  There are some other items in the Entrys that I need too, 
>> such as icons.  Any of the Entry objects that I need access to, and any classes 
>> which they are dependent on, and which are publicly visible classes/interfaces, 
>> because of that attribute (public) can not be realistically preferred.
>>     
>
> I think I'm with Dan here - looks to me like a misuse of LUS. I see it
> as a more or less dumb bootstrap mechanism - designed for _lookup_ not
> _browsing_ .
> Wouldn't a ServiceBrowserService (or a ServiceIndexingService) be a
> solution?
>
> Michal
>
>   

Can you give an example?

Peter.