river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: MarshalledServiceItem
Date Wed, 02 Feb 2011 08:07:37 GMT
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?


View raw message