Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4A6F3DD6.2010606@cox.net>
Date: Tue, 28 Jul 2009 13:05:10 -0500
From: Gregg Wonderly <gergg@cox.net>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
References: <F5DF5420-6DCA-4873-A8E4-8E9F501D5CB3@mac.com>
	 <964EAC824495234A86F3C47DA8BD8AAD1776B4@sucden-exch.sucden.co.uk>
	 <e736790907141447m6693edbev30729b11846da897@mail.gmail.com>
	 <4A5D0B72.6080103@wonderly.org>
	 <e736790907141612v70c00da2xa6caddbf9a43d130@mail.gmail.com>
	 <4A5F8695.2040603@cox.net>
	 <caf30e2a0907192314m1a9d0ae0n57bd1f12dd96f18d@mail.gmail.com>
	 <4A674C7F.5060309@wonderly.org>
	 <caf30e2a0907230142q3c5d0967x6750b02ebd812e7@mail.gmail.com>
	 <4A6DFDD1.9000109@cox.net>
 <caf30e2a0907272033t4fd34077m8d7e236bb46f16e9@mail.gmail.com>
In-Reply-To: <caf30e2a0907272033t4fd34077m8d7e236bb46f16e9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niclas Hedhman wrote:
> On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<gergg@cox.net> 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.

I said a lot of different things in different ways that didn't help me make the 
point, sorry for that.

1.  You can't take the existing LUS mechanism and extend the API for 
registration without making something visible in lookup.

2.  You can't take the existing, marshalled values, and unmarshall them to look 
at "strings" or other "data" for matching, so the new registration data has to 
be represented as a "special" case and not part of what already happens.

3.  Specialization can happen by using method signature changes, special Entry 
types, or by layering lookup into something that uses the existing mechanisms in 
ServiceRegistrar, but does something with the registration data.

For example, what if we created maps for each Entry that were

"com.my.company.package.EntryClass.fieldName" ==> "The string value"

for all fields that were native types?  If we then transported that data
inside of the existing MarshalledInstance as separate data that was made 
available on (my reef impl's) ServiceLookup interface, then a new RFC-119 lookup 
could be implemented by looking for ServiceLookup on the ServiceRegistrar proxy, 
and then getting the map of values and doing string comparisons.

> 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.

I believe that neither side really had any productive conversations other than 
"why don't you do XXXX it's what we need to integrate these technologies".

We needed to have the "why did you do it that way" conversations to help 
everyone appreciate each others perspectives.

Supporting RFC-119 means we need a new lookup mechanism that doesn't cause 
unmarshalling.  I have in mind one way to implement that on top of reggie so 
that existing service registrations don't have to change what the do, only what 
version of reggie they register with.

The use of type based lookups and supporting a new API for string based lookups 
with expressions etc doesn't mesh well with marshalled data unless you segregate 
what should be used from what is not interesting.  Jini Entry objects can have 
very complex values in them, and unmarshalling is the "most robust" way to see 
those types for "user code".  For the Reggie internals, the details are more 
visible because of how the "MarshalledInstance" is created.  Exposing those 
details in a way that doesn't cause "downloading" or "unmarshalling" (which can 
lead to codebase contamination because of local class uses) is what is left to do.

Gregg Wonderly