river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <mic...@kleczek.org>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 08:11:00 GMT
We are talking about the same thing.

We are turning circles, Peter - all of this has been already discussed.

1. Yes - you need to resolve bundles in advance (in OSGi it is not 
possible to do otherwise anyway)
2. You cannot decide upon the bundle chosen by the container to load the 
proxy class (the container does the resolution)
3. The runtime graph of object places additional constraints on the 
bundle resolution process (to what is specified in bundles' manifests).
Since you do not have any way to pass these additional constraints to 
the container - the case is lost.

Additionally - to explain what I've said before about wrong level of 
abstraction:

Your general idea is very similar to mine: have a special object (let's 
call it installer) that will install software prior to proxy unmarshalling.

1. For some reason unclear to me you want to constrain the way how this 
"installer object" is passed only via the route of ServiceRegistrar (as 
attributes)
But why not:

public interface RemoteEventProducer {
   void registerListener(SmartProxyInstaller installer, byte[] 
remoteEventListenerBytes);
}

I cannot see a difference at all and this is why I say that mixing 
ServiceRegistrar and ServiceDiscoveryManager
into it is really mixing levels of abstraction (and does not add 
anything to the solution).

2. If you allow to pass "installer" to unmarshall proxies - then the 
next question is - why do you require doing it explicitly in the 
application code???
THIS is really mixing levels of abstraction. A programmer expects a 
natural programming model (and will not buy into Jini if it does not 
offer such):

registerListener(RemoteEventListener listener);

without any additional complexities that should be solved by the 
infrastructure code.

3. But the above is easy to solve:

class UnmarshallingInvocationHandler implements InvocationHandler {

   private Object unmarshalledProxy;
   private SmartProxyInstaller installer;

   writeObject(...) { write out installer and proxy bytes }
   readObject(...) {read installer then bytes and then unmarshall the proxy}

}

4. But then the next question is why not put it in the object stream 
implementation itself???

Thanks,
Michal


Peter wrote:
> Also see the OSGi Enterprise specification, v6, Chapter 136, page 691, 
> there's some discussion about the NP-complete nature of dependency 
> resolution there as well.
>
> https://www.osgi.org/developer/downloads/release-6/release-6-download/
>
> On 13/02/2017 5:19 PM, Peter wrote:
>> OSGi Dependency resolution is.
>>
>> http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html

>>
>>
>> Which means if we want to support an OSGi environment properly, we 
>> may need some time to resolve the dependencies for a smart proxy, 
>> before deserializing the proxy, rather than downloading the proxy 
>> dynamically during unmarshalling, it's better to delay unmarshalling 
>> until the dependencies are resolved, so the client isn't impacted by 
>> delays.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 13/02/2017 4:50 PM, Michał Kłeczek wrote:
>>> Sorry, NP Completness of what?
>>> I have been the first to mention NP hardness of constraint 
>>> satisfaction problem
>>> but I am not sure if this is what you are asking about.
>>>
>>> Thanks,
>>> Michal
>>>
>>> Patricia Shanahan wrote:
>>>> Are you literally claiming NP Completeness, or just using that as 
>>>> an analogy for really, really difficult?
>>>>
>>>
>>>
>>
>>
>


Mime
View raw message