On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<[email protected]> wrote:
> The issue which I think is never fully considered is that lookup is based on > the Java type system, including complex types, and not based on string > matching. If it was just string matching, we'd have RE support now. But > there is no defined RE syntax for "derived from" or "implements X" etc. The > Java type system provides that. Yes, that is the view of "Jini Zealot" ;-) and their argument is that Jini Lookup can't do algorithms and arithmetic. And as long as either side don't want to look for the converged solution, this status quo will remain, just like when I first brought this up 2-3 years ago. And Kriens & Co at OSGi will have the same 'we are so much better' attitude as well... > I will concede that the mechanics of matching in reggie are a > reimplementation of the type system semantics, because code is not > unmarshalled (as a versioning, code corruption, and security measure, at the > least). This is just a result of the initial decision to have Entry and inheritance as the basis for service attributes. Another decision could have been made that we only allow named properties, where the name is a String and the Value is any one of the following immutable types... In retrospect, can you really claim that the way Jini chose is superior an alternate route? I am not so sure... > I'm more than willing to put together a new lookup service that does provide > "string only" lookup of Entry.toString() values. It would be possible to > include new data, taken from the Entry values before they are marshalled for > transport. > > My changes to reggie to support deferred downloading, include the packaging > of all class and interface names as part of the MarshalledInstance so that > you can ask if an Entry (or the service itself) "is a" without having to > unmarshall it. This proposal sounds like a hack. You are trying to work around marshalling, since you have made the choice that it should be marshalled. Be more bold and drop Entry, go with named attributes and see where it takes you. > There are lots of things that I suspect the OSGi camp is only now > discovering to be necessary "evils". Perhaps... or not. I think the current stock of solutions are mostly WS-* related, and they just inherit the problems under the hood. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
