river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Sun, 23 May 2010 05:53:28 GMT
Dennis Reedy wrote:
> 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:
>>     
>
> Oops, but no. If the service does not have a DL jar, the ServiceItem will not be able
to be loaded by reggie, so joining the network is a problem
>
>   
Are you sure?

Doesn't Reggie only use Marshalled from?

We need to make sure that the Service API is down-loadable for clients.  
I expect that in future we'll make the API browseable, so clients can 
download the API prior to lookup.  Also the client knows the API prior, 
if designed for it.
Well, we could name them like this:

Service Implementation jar: 	service.jar (depends on service-api.jar)
Service API jar: 		service-api.jar (make sure this can be downloaded too)
Smart Proxy jar: 		service-smart-proxy-dl.jar (depends on service-api.jar)


What do you think?

As long as we ensure that the Service API is available for download too, 
we should be fine.

Rather than encapsulate the Service API within the service.jar, I'd like 
to keep it separate from the implementation, for the same reasons the 
smart proxy is.

The API is the common interface, if placed in a parent ClassLoader, it 
solves the majority of ClassLoader visibility issues that have beset 
Jini over the years.

The smart proxy becomes isolated and has it's own private class 
namespace, apart from the platform and API classes, so it will never 
step on application code toes.

-Pete.





Mime
View raw message