river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Codebase service?
Date Mon, 24 May 2010 13:32:45 GMT
Making this nomenclature change (-dl.jar -> -proxy.jar) will help identify a 
services "vintage" as being "of the new paradigms" to help one understand what 
to expect perhaps?

Gregg Wonderly

Dennis Reedy wrote:
> Peter 
> 
> Ok, this works for me. Perhaps we should make it more abundantly clear and change service-dl.jar
to service-proxy.jar?
> 
> Smart Proxy:
> 
>   Implementation jar:    service.jar (depends on service-api.jar)
>   API jar:                       service-api.jar
>   Smart proxy jar:         service-proxy.jar (depends on service-api.jar)
> 
> Dumb Proxy:
> 
>   Implementation jar:    service.jar (depends on service-api.jar)
>   API jar:                       service-api.jar
> 
> 
> On May 22, 2010, at 834PM, Peter Firmstone wrote:
> 
>> Dennis Reedy wrote:
>>> On May 22, 2010, at 646PM, Peter Firmstone wrote:
>>>
>>>  
>>>> Dennis Reedy wrote:
>>>>    
>>>>> On May 20, 2010, at 628PM, Peter Firmstone wrote:
>>>>>
>>>>>       
>>>>>> We could call it api, instead of spec, so as not to confuse the Jini
Spec?  (We call River an implementation of the Jini Specifications)
>>>>>>
>>>>>> Implementation jar: service.jar
>>>>>> API jar: service-api.jar
>>>>>> Download jar: service-dl.jar
>>>>>>
>>>>>>           
>>>>> Thinking out loud here, what id the service does not use a smart proxy?
There is no difference between the API jar and the DL jar. Is the API jar only needed when
the service uses a smart proxy?
>>>>>       
>>>> Yep that's correct.
>>>>    
>>> So as far as a convention is concerned here, what would you recommend? Only create
API jar for smart proxy implementations? Or only create DL jars for smart proxy implementations.
>>>
>>> Seems that the latter makes more sense? If so than the API jar will always be
in the client's classpath. Will have problems with the service's registration with reggie
though.
>>>  
>> No, this would be more appropriate:
>>
>> Smart Proxy:
>>
>>   Implementation jar:     service.jar (depend on service-api.jar)
>>   API jar:                       service-api.jar
>>   Download jar:             service-dl.jar (depend on service-api.jar)
>>
>>
>> Dumb Proxy:
>>
>>   Implementation jar:     service.jar (depend on service-api.jar)
>>   API jar:                       service-api.jar
>>
>> That way, your free to implement a smart proxy service later if you want to move
processing to the client or vice versa.
>>
>> Most importantly we want to promote others to standardise on popular service-api.jar's
available on Maven's repositories.
>>
>> The ClassLoader structure I have in mind will load all API (hence dumb proxy's too)
into the Jini Platform ClassLoader, they will be protected by the Service-api.jar ProtectionDomain.
O:-)
>>
>>
> 
> 


Mime
View raw message