river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Codebase service?
Date Mon, 24 May 2010 13:07:29 GMT
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