My griddle project on Java.net investigated the notion of using smart comparisons for equality. Basically, griddle separates the keys from the object. The keys are managed and matched by a matching implementation. The intent is that key values would be native types, not downloaded types, but downloaded types are not forbidden. This would allow you to ask a much richer question for “watch matches” by sending your read request or take request with an executable matcher which could do ranges or sets etc.
Gregg > On Jul 26, 2016, at 11:21 PM, Peter <j...@zeus.net.au> wrote: > > Also, there's no reason why logical comparisons cannot be made with numerical > objects during lookup. > > Although the Entry spec suggests that entry fields are marshalled as > MarshalledObject's, reggie doesn't do this for immutable value objects like > Integer etc. > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Peter <j...@zeus.net.au> > Sent: 27/07/2016 09:42:09 am > To: dev@river.apache.org <dev@river.apache.org> > Subject: Re: another interesting link > > Discovery and lookup are akin to search engines, but distributed rather than > reliant on large corporations. > > With IPv6 global announce, it's possible to perform global search and this is > where another of Gregg's innovations, delayed unmarshalling, is very > important to minimise local processing. > > Regards, > > Peter > > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Gregg Wonderly <gr...@wonderly.org> > Sent: 27/07/2016 02:09:50 am > To: dev@river.apache.org > Subject: Re: another interesting link > > More formal interface libraries were supposed to solve that problem so that > you would have a formal name for such contracts. That would be the Jini way > to start working this direction. The classic issue is that people believe > that HTTP is the interface of today. They don't understand how POST is > contractually equivalent to Jini's invocation layer. > > The path in a URL is the method name and the payload is the same as > arguments. What is possible with Jini is to use lookup instead of hardcoded > URLs. People are using hostnames for lookup services and being satisfied. > > Gregg > > Sent from my iPhone > >> On Jul 26, 2016, at 8:41 AM, Michał Kłeczek (XPro Sp. z o. o.) >> <michalklec...@xpro.biz> wrote: >> >> I am well aware of StartNow since that is the first Jini "support library" >> I have used. Indeed - it is really easy to use. >> But it is only one side of the issue - the API and some support support >> code that is supposed to be linked statically with the service >> implementation. >> >> What I am talking about is actually "externalizing" most aspects of a >> service implementation so that: >> - you do not have to package any (for some meaning of "any" :) ) libraries >> statically (since all code can be downloaded dynamically) >> - you do not have to provide any (for some meaning of "any" :) ) static >> configuration (ie. configuration files) - a service should simply use other >> services and "reconfigure" itself when those change >> It would go towards some kind of an "agent architecture", with movable >> objects (ie "services") being "hosted" by well... other movable objects :). >> The idea is less appealing today when we have all the cloud infrastructure, >> virtualization, software defined networking etc. Nevertheless still >> interesting IMHO. >> >> Thanks, >> Michal >>> Gregg Wonderly July 26, 2016 at 1:28 PM >>> My StartNow project on Java.net aimed directly at this mode of operation a >>> decade ago. I wanted conventions that provided use of configuration with >>> defaults. >>> >>> You just extend PersistantJiniService and call start(serviceName). >>> Subclasses could override default implementation for how the conventions in >>> the APIs created implementation objects through code or configuration. >>> >>> The intent was to create THE API to provide the conventions of service >>> creation. >>> >>> We have a Window/JWindow class and don't have to do all the decorating >>> ourselves. >>> >>> Jini service construction should work the same way! >>> >>> Gregg >>> >>> Sent from my iPhone >>> >>> >>> Tom Hobbs July 26, 2016 at 11:50 AM >>> I would say the comment on that blog sums everything about Jini up. >>> >>> It’s just too hard to set up and get working >>> >>> That’s why I think simplifying reggie is possibly a first step. Make a >>> /small/ and simple reggie jar that just handled service registration and >>> not proxy downloading etc. Make it really easy to register your services >>> without needing class loaders etc, preferably via some convention rather >>> than configuration. (This is what I’m trying to find the time to work on.) >>> >>> I’d really like to be able to type; >>> >>> $ java -jar reggie.jar >>> >>> And have a reggie running with all the defaults ready to register my >>> services with. Or perhaps, as an option; >>> >>> $ java -jar reggie.jar —ipv6 >>> >>> Security, class loading, proxy downloading and all the rest of it could >>> then be put back in by specifying more advanced configuration options. >>> >>> My Scala service would be great if I could define it just as; >>> >>> object MyCoolService extends LazyLogging with ReggieRegistration with >>> ReggieLookup >>> >>> Or in Java with default interface methods; >>> >>> class MyCoolService implements ReggieRegistration, ReggieLookup >>> >>> And that would be it, congratulations you’ve started a reggie and >>> registered your service and have methods available to help you find other >>> services. >>> >>> This would satisfy use cases where the network was private and/or trusted. >>> And security on top would, ideally, be up to configuration again or perhaps >>> injecting some alternative implementation of some bean somewhere. But the >>> core premise is, make it easy to startup, demo and see if it fits what you >>> want it for. >>> >>> >>> >>> >>> Peter July 26, 2016 at 3:58 AM >>> Note the comment about security on the blog? >>> >>> Steps I've taken to simplify security (that could also be adopted by >>> river): >>> 1. Deprecate proxy trust, replace with authenticate service prior to >>> obtaining proxy. >>> 2. proxy codebase jars contain a list of requested permissions to be >>> granted to the jar signer and url (client need not know in advance). >>> 3. Policy file generation, least privilege principles (need to set up >>> command line based output for admin verification of each permission during >>> policy generation). >>> 4 Input validation for serialization. >>> 5. DownloadPermission automatically granted to authenticated registrars >>> (to signer and url, very specific) during multicast discovery. >>> >>> Need to more work around simplification of certificate management. >>> >>> Regards, >>> >>> Peter. >>> Sent from my Samsung device. >>> >>> Include original message >>> ---- Original message ---- >>> From: Peter <j...@zeus.net.au> >>> Sent: 26/07/2016 10:27:59 am >>> To: dev@river.apache.org <dev@river.apache.org> >>> Subject: another interesting link >>> >>> https://blogs.oracle.com/hinkmond/entry/jini_iot_edition_connecting_the >>> >>> >>> Sent from my Samsung device. >> > >
