Hi,
Have a look at the latest commit, while I haven't enabled anything other
than exact matching for Entry's in Registrar, I have created some
interfaces that:
* Allows unmarshalling to be delayed by the client.
* Allow selected Entry's to be unmarshalled for filtering, see
MarshalledServiceItem, an abstract class that extends ServiceItem,
see also StreamServiceRegistrar.
* Created a new class that utilises multiple combinations or chains
of ServiceItemFilter filters, so these might be combined in a
selectable user interface with AND OR logic. Developers who have
created ServiceItemFilter's over the years will be able to utilise
them in new ways. Filters that only compare Entries can be
utilised prior to unmarshalling, those that require access to the
proxy to apply MethodConstraints filters or Proxy Verification
filters can be applied after unmarshalling.
I intend to enable very large result sets to be incrementally returned
while also allowing filters and comparisons based on Entry's to be
executed locally prior to unmarshalling the service, so that
unmarshalling is reduced to the utmost minimum.
The existing Registrar unmarshalling semantics and proxy verification
etc can be preserved, without exposing the implementation in River's
Jini public API.
I would like comments from the Original Authors (if possible & time
permitting), so that I can fully understand any implications of these
changes.
These changes are intended to make it possible to implement lookup
globally. Result sets can be narrowed down significantly using
filtering before unmarshalling and operations can be performed on
batches of lookup results (services) that can be discarded after
operation, allowing Garbage Collection to clean up de-referenced Class
files and ClassLoaders during ongoing lookup result processing, while
removing unnecessary codebase downloads.
I'd also like to further reduce codebase downloads by allowing packages
and codebases to be shared based on package versioning. Security
implications are that a codebase would have to be signed by a trusted
party, treated separately from the service, which might need to
authenticate itself if required by the client, I don't know how to
enable the Service to specify a constraint on the signer of the
downloaded codebase if not originating from the service, any ideas?
Note that this implementation is intended to not break backward
compatibility.
Best Regards,
Peter Firmstone.
