Interesting thanks Gregg, you've pushed the envelope on a number of fronts!.

Cheers,

Peter.

On 2/08/2016 4:26 AM, Gregg Wonderly wrote:
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.




Reply via email to