Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A685390.6090002@zeus.net.au>
Date: Thu, 23 Jul 2009 22:12:00 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
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>
 <4A674C7F.5060309@wonderly.org> <4A67E2D5.5030109@zeus.net.au>
 <200907230941.22897.michal.kleczek@xpro.biz>
In-Reply-To: <200907230941.22897.michal.kleczek@xpro.biz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michael,

That would be very much appreciated.

Best Regards,

Peter.

Michal Kleczek wrote:
> On Thursday, 23 of July 2009 06:11:01 Peter Firmstone wrote:
>   
>> HTTP codebase's are part of the problem, the URLClassLoader is fixed in the
>> object's Type (class identity), which may change over time.  Michael Warres
>> addressed this problem by creating a dynamic codebase service where the URL
>> was a cryptographic hash of the jar file (stored data) identity.
>>
>> Michael made a presentation on Service based codebases, apparently not
>> much code was required to implement it.  We cannot directly copy the
>> code (interfaces etc) from the presentation due to copyright, although
>> we can produce functionally equivalent code.
>>
>> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>>
>>     
>
> We have implemented a similar solution in XPro.
> The main difference is that in our implementation there is no "put" operation 
> in a ContentAddressedStore interface. In other words:
> 1. Each service publishes a separate ContentAddressStore and becomes its own 
> codebase server.
> 2. You can run specialized services that cache resources from other 
> ContentAddressStores to achieve HA
> 3. Optionally you can configure the services to act in a P2P fashion - the 
> resources downloaded by a service are also published.
>
> The main motivation behind this was to be able to run services with minimal 
> dependencies on other services being available on the network.
>
> After resolving some licencing problems (which should not be very complicated 
> I think) we could contribute this code to River.
>
> Thanks,
> Michal
>
>