Re: Using ServiceStarter to launch a "proxy is service" service
Dan Creswell <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Gregg Wonderly wrote: > Dan Creswell wrote: >> I'd say it's almost a Jini Service philosophy kind of thing - "when >> programming Jini Services consider the keepalive problem, here's what's >> recommended for the back-end/proxy situation, here's what's sane for the >> proxy only situation" and so on. > > Yep, I can see it both ways. I'm just thinking more about the service > registration being a two way agreement which JoinManager and the API > don't really have lined up. > Yeah - been down that path, I agree with the "both ways" thing. >> Feels maybe like a pattern we should write up somewhere more than a code >> fix? > > Definately should document it some how. Not sure whether that's just > text, which to date we've had a hard time using to "teach" people about > Jini, it seems (not sure, just reflecting on the types of questions we > get typically) or an API representation that reveals the considerations > where developers would be looking. > Back to the old question of what goes in JavaDocs and what goes "elsewhere" and what "elsewhere" is..... I think it's clear that what we put in JavaDoc is not what most people expect. We all prefer it because: (1) It's quite detailed and specific unlike bits of the JDK and it seems our mindsets are such that we like this (2) We've grown up with things this way ......but it seems like we saturate most other people. Maybe we need to drag stuff out of the JavaDoc and link to it on the side or something instead so's we can control detail. And I think the "elsewhere" is some high-level programming philosophy type document and no doubt plenty of people will want it online (my paranoid side says, "so they can get it for free") and if that's the case, I don't know what format to use, how searchable to make it etc. > I'm also thinking about a layered JoinManager thing too, which might > expose registration of services, but allow plugability of the > registration entity in case ServiceRegistrar is not desired. > Yep been tempted by that as well - there are certainly times when I'd like to know a little more of what's going on inside of the JoinManager. Re: pluggability - maybe, but my normal tendency is to write a wrapper for the other entity which looks like a ServiceRegistrar but isn't. i.e. Use service composition and keep the integration code well-confined rather than leak it into core APIs. > I've still got my ServiceLookup implementation that I need to cast into > an API that works for multiple types of registration entities, and so I > still consider this an important issue. > > Gregg Wonderly > Dan. -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected]