This would be a DHCP like lease scheme.
Gregg
> On Jan 25, 2017, at 7:30 PM, Michał Kłeczek (XPro Sp. z o. o.)
> <michal.klec...@xpro.biz> wrote:
>
> I also think about adding leasing to the scheme.
> If CodeBaseModule can be leased (and the client is capable of handling
> declines of lease renewals) - it would be quite straightforward to implement
> auto-upgrade: the lease for a module "mymodule" ver 1.1 expires and you have
> to ask the code server for a new CodeBaseModule - which in turn could return
> a newer patched version of it.
>
> Cheers,
> Michal
>
> Michał Kłeczek (XPro Sp. z o. o.) wrote:
>> So for a client and a service to be able to communicate they must agree on a
>> common set of interchangeable CodeRepositories that would allow them to have
>> a common understanding of names.
>> In other words - to be able to work - any party first has to contact a
>> CodeRepository that can authenticate itself as a particular principal. The
>> issue is that to find the CodeRepository one needs to communicate with
>> ServiceRegistrar. And to communicate with ServiceRegistrar you need a
>> CodeRepository!!!. So there needs to be some bootstrapping in place:
>> - either ServiceRegistrar and CodeRepository constitute as single entity
>> - there is a bootstrap well known CodeRepository (Maven central?) - its
>> implementation is based on a well known URL and its implementation code is
>> shipped with the framework.
>>
>> Thanks,
>> Michal
>>
>> Michał Kłeczek (XPro Sp. z o. o.) wrote:
>>> Honestly - since I am fixed ( :-) ) on having mobile code treated as any
>>> other object - I see it something like:
>>>
>>> interface CodeBaseModule {
>>> ClassLoader createLoader() throws AnyImportantException;
>>> }
>>>
>>> interface CodeRepository {
>>> CodeBaseModule getCodeBaseModule(String name, Version version);
>>> boolean isSameNamespace(CodeRepository other);
>>> }
>>>
>>> class NamedCodeBase {
>>> String name; Version version;
>>> CodeRepository repository;
>>> boolean equals(Object other) { //check name, version and repo }
>>> }
>>>
>>> Now the question is about the implementation of "isSameNamespace". Since
>>> the protocol(s) to access code repository might differ (and there might be
>>> multiple available at the same time), location based equality won't work
>>> (although is the easiest to implement). My rough idea is for the
>>> CodeRepository to be able to authenticate as any of a set of Principals (
>>> ie. satisfy the ServerMinPrincipal constraint ). Two CodeRepository
>>> instances are interchangeable if intersection of their principal sets is
>>> non-empty.
>>>
>>> At first I thought about having a global naming scheme - then cryptographic
>>> hash would constitute the part of the name. But that would make names
>>> obscure and difficult to remember and write by hand.
>>> So I came up with an idea to abstract it away - according to "all problems
>>> in CS can be solved by introducing another level of indirection" :)
>>>
>>> Thanks,
>>> Michal
>>>
>>> Peter wrote:
>>>> codebase identity
>>>>
>>>> So River codebase identity is currently any number of space delimited RFC
>>>> 3986 normalised URI strings.
>>>>
>>>> httpmd uses a location filename and message digest.
>>>>
>>>> But should location be part of identity? How can you relocate a codebase
>>>> once remote objects are deployed?
>>>>
>>>> OSGi and Maven use a name and version to identify a codebase.
>>>>
>>>> Might we also need codebase signers (if any) to be part of identity?
>>>>
>>>> If no, why not and if yes why?
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Sent from my Samsung device.
>>>>
>>>> Include original message
>>>> ---- Original message ----
>>>> From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
>>>> <mailto:michal.klec...@xpro.biz>
>>>> Sent: 26/01/2017 08:30:58 am
>>>> To: d...@riverapache.org <mailto:d...@riverapache.org>
>>>> Subject: Re: OSGi
>>>>
>>>> I haven't been aware of ObjectSpace Voyager. I just briefly looked at it
>>>> and it seems like it is based on Java 1.x (ancient beast) and - as I
>>>> understand it - the issues you describe are mainly caused by having only
>>>> a single class name space (single ClassLoader).
>>>>
>>>> But sending IMHO class bytes in-band is not necessary (nor good).
>>>>
>>>> What is needed is:
>>>> 1. Encoding dependency information in codebases (either in-band or by
>>>> providing a downloadable descriptor) so that it is possible to recreate
>>>> proper ClassLoader structure (hierarchy or rather graph - see below) on
>>>> the client.
>>>> 2. Provide non-hierarchical class loading to support arbitrary object
>>>> graph deserialization (otherwise there is a problem with "diamond
>>>> shaped" object graphs).
>>>>
>>>> A separate issue is with the definition of codebase identity. I guess
>>>> originally Jini designers wanted to avoid this issue and left it
>>>> undefined... but it is unavoidable :)
>>>>
>>>> Thanks,
>>>> Michal
>>>>
>>>> Gregg Wonderly wrote:
>>>>> That’s what I was suggesting. The code works, but only if you put the
>>>>> required classes into codebases or class paths. It’s not a problem with
>>>>> mobile code, it’s a problem with resolution of objects in mobile code
>>>>> references. That’s why I mentioned ObjectSpace Voyager. It
>>>>> automatically sent/sends class definitions with object graphs to the
>>>>> remote VM.
>>>>>
>>>>> Gregg
>>>>>
>>>>>> On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o.
>>>>>> o.)<michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> wrote:
>>>>>>
>>>>>> The problem is that we only support (smart) proxies that reference only
>>>>>> objects of classes from their own code base.
>>>>>> We do not support cases when a (smart) proxy wraps a (smart) proxy of
>>>>>> another service (annotated with different codebase).
>>>>>>
>>>>>> This precludes several scenarios such as for example "dynamic
>>>>>> exporters" - exporters that are actually smart proxies.
>>>>>>
>>>>>> Thanks,
>>>>>> Michal
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
