On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<[email protected]> wrote:
> It comes down to whether that logic really must live in the lookup, or in > the client. And, as many people have said before, you can write a new > lookup "service" that uses these features and have your application lookup > that lookup server by interface, and then call methods on it to find the > matches. Ok, let's examine such "Named Service Properties Lookup"; 1. It defines that each service can have N key-value pairs; No problems. 2. It will have a service interface that allow the lookup in OSGi syntax. No problems. 3. It will either require; a. That the service explicitly register itself at it. b. That the NSPL lookup all other services on the federation and extract the key-value pairs somehow, and possibly allow annotation of it independently. 3a is to me equal -> Will not be promoted, therefor not used. 3b is possible but seems like a big hack, compared to complementing the API with key-value mapped attributes and an expression language not executed by unmarshalling any service proxies. > Let me restate one thing, which I really don't think people appreciate. > Unmarshalling services in a client is EXPENSIVE. If you are picking 1, from > 100 instances by executing some code that the service proxy provides, there > will be problems. Isn't the above a strong argument against "let the client do it"? First do a general lookup, which provides 20 services, transport and unmarshall those service proxies to the client, and then inspect further. That can't be the way to do it, and I don't think you promote that either with your "It comes down to whether that logic really must live in the lookup, or in the client." statement, but it is how I initially read it. > The basic issue from my perspective is that if people don't talk about > specifics, but only generalize about the issues, resolution doesn't happen > very fast. I try to talk about specifics, Well, I agree that "actual usecases" are superior in discussions. But there are psychological problems as well. Once you say "My solution is superior because...", then the recipient will stop listen and go into defense mode to find cracks in the armor (your argument), and will counter (in this case), "Ha, rubbish. You can't even do arithmetic lookup.". From then on the discussion is over and it becomes a religious/political game of 'mine is longer than yours'... I am not here anymore to try and get OSGi and Jini communities to converge. That battle is long ago over, and both sides (IMHO) lost, since they didn't get a single inch closer. OSGi has the "we can do it all"-attitude at the moment, and the distributed solution (at API/SPI level) has been formulated and solutions worked out. Jini community can no longer become a 'contributing participant', and that is a shame. River *could* choose to be 'conformist', i.e. take the RFC-119 spec and implement it with Jini technology, and in that process see what 'new things' (detailed as you call it) would surface for Jini. Organizationally, OSGi allows the public to write so called RFPs. Those are "Requirement" docs which outlines the need, but don't touch on the solution. The RFPs are expected to be extremely usecase-oriented with hypothetical (or real) walk-thrus of what is needed. Feel free to contribute the need for type hierarchies in service lookups. Personally, I like both Jini and OSGi, but regretfully I am currently not working actively on either one of them (offers welcome ;-) )... And I should be the last one to say what the communities should do to move forward. 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
