Brent Verner wrote:
Eh, this sounds interesting. Any particular application in mind targeting the framework?
Nothing real specific, no. I sort of visualize it as a generic
way of making it easier to do parallel / distributed programming with
Java. One of the key ideas is to keep the interface as similiar to "real" Threads (java.lang.Thread) as possible, to keep the learning
curve to a mininum. Of course, it may never amount to anything.
Strange that I ended up having to solve this same problem--allowing a remote client to bind a Remote into the registry. Actually, as you state, that can't be done directly, but I wrote my own registry whose Registry methods used an ExecutorService to call the underlying registry, getting around the non-local check of the Sun RegistryImpl that my RegistryImpl extended. Quite a neat hack, methinks :-)
I thought about doing something like that, but it seemed like too much work. I'd planned all along on supporting alternate registries, so I was just forced to deal with that sooner rather than later. I hope to get it working with OpenLDAP as well. I've played with storing Java objects in OpenLDAP before, and it sorta worked.
Ah, I see, you don't have a requirement for the Java RMI. I wish I had the luxury of using an alternate RMI, because I wouldn't choose
the standard Java RMI.
Well, I am using the standard RMI, just not the standard naming / directory service. Although I would like to look into what it takes
to replace the underlying RMI "plumbing" with a different implementation. I know it's possible, but I've never tried it
that way.
TTYL,
Phil -- North Carolina - First In Freedom
Free America - Vote Libertarian www.lp.org
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
