ServiceProxyAccesor is an interface in the start package, a similar interface called ProxyAccessor exists in the net.jini.export package.
The difference between these two interfaces is the former returns a smart proxy, which may not be a Remote object, while the latter returns the Remote proxy which is a reflective proxy or remote proxy stub. Often, the former contains the latter, where the former implements service api, while the latter is used for remote communication with the service's server. In a future version of River, ServiceProxyAccessor could be used by clients to obtain the service proxy, from a bootstrap proxy, allowing authentication to occur prior to codebase download and unmarshalling. Think security and delayed unmarshalling. If this was to occur, we'd need to change the package for the ServiceProxyAccessor interface, to net.jini.export. Seeing as we're about to change the package of ServiceProxyAccessor in the 3.0 release, it would have less impact on downstream code if this change was only made once. If the security and performance improvements were not accepted, (I'm quite confident that we will agree on a solution once the benefits can be demonstrated) it still makes sense to move ServiceProxyAccessor to net.jini.exporter due to their related use and functionality. Should I proceed with a vote to move ServiceProxyAccessor to net.jiniexporter now, prior to release, or should I leave it until River 3.1? This wont cause a delay in the release process, but I'm happy to leave it if anyone is concerned it will. Regards, Peter. Sent from my Samsung device.
