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:-)
