river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <kleczek.mic...@gmail.com>
Subject Re: MarshalledServiceItem
Date Wed, 02 Feb 2011 09:00:50 GMT
On Wed, 2011-02-02 at 18:07 +1000, Peter Firmstone wrote:
> >> First, let's look at the simple client mechanisms I wanted to have.  I have
> >> desktop environment, which does lookup, and then shows treeviews of services

> >> based on "machine"->"group"->Service Instance structure.  The deployed
> >> contain Entry objects that provide values for these three name spaces.  Since
> >> 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
> >> 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?
> >
> Can you give an example?

import javax.swing.tree.TreeModel;

//the service is deployed in a Djinn - it keeps track of all available
//services and indexes them so that the client can just use a TreeModel
//to display available services
interface ServiceBrowserService {
  TreeModel getServiceTree();

Don't really know what example you need - the point is that the problems
Greg described don't really have to be dealt with by the client but by
one of the services in Djinn that would provide clients with a _view_ of
all available services.

"All problems in a Djinn can be solved by another service".


View raw message